From Michael.Wojcik at microfocus.com Sun Sep 1 13:32:29 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Sun, 1 Sep 2019 13:32:29 +0000 Subject: BIO_read fails when performing DTLS handshake In-Reply-To: References: <2b72244c-7179-5f82-1ae5-13d1af453849@gmail.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matthew > Sent: Saturday, August 31, 2019 14:40 > Is it normal for an SSL's readBio to be empty right after DTLSv1_listen? Offhand I don't know. I've never used DTLS. Perhaps someone who knows more about it will join in. -- Michael Wojcik Distinguished Engineer, Micro Focus From matt at openssl.org Mon Sep 2 08:41:41 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 2 Sep 2019 09:41:41 +0100 Subject: BIO_read fails when performing DTLS handshake In-Reply-To: References: <2b72244c-7179-5f82-1ae5-13d1af453849@gmail.com> Message-ID: <18ca72ae-14de-110b-2b5b-67901996980c@openssl.org> On 31/08/2019 19:40, Matthew wrote: > Hi Michael, > > > Of course I should have provided a version: 1.1.1c, on linux-x64 (dotnet core 2.2) > > Just a quick question while I prepare a clearer, more contextual and concise > email about my problem; > > Is it normal for an SSL's readBio to be empty /right/ after DTLSv1_listen? > > I noticed that after calling DTLSv1_listen, and it returning 1, the SSL's > readBio's bytes pending = 0. Would this not force the client to send a second > hello with cookie? Or does DTLSv1_listen perform the clientHello processing and > then let SSL_accept send the response? DTLSv1_listen() (in 1.1.1c) does the following (simplified): - Listens for incoming ClientHellos - Reads the ClientHello from the underlying BIO - Checks to see if the ClientHello contains a cookie or not - If the cookie is NOT present then it sends a HelloVerifyRequest back and goes back to the first step above - Otherwise it verifies the coolie. If verification fails then it sends a HelloVerifyRequest and goes back to the first step above. - Otherwise if verification succeeds then it buffers the received ClientHello record internally in the SSL object and returns 1 So it is normal after DTLSv1_listen() for the BIO to be empty because it has already read the ClientHello and has buffered it internally. Note that running DTLS over a mem bio may not always work as expected. Mem bio's are implemented conceptually as a stream. Therefore they do not respect packet boundaries and so you may get unusual behaviour. Additionally it doesn't support any of the datagram related ctrls that a dgram BIO supports. Therefore it can't do things like identify the address of the peer and query the MTU of the link. In other words I would recommend using dgram bio rather than a mem bio. Matt > > On 2019-08-31 10:51 a.m., Michael Wojcik wrote: >>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matthew >>> Sent: Friday, August 30, 2019 23:06 >> Welcome to the list. When posting, please remember to tell us what version of OpenSSL you're using, and what platform you're on. >> >> Since you're talking about C#, I'll assume the platform is Windows. And I'll assume you're working with OpenSSL 1.1.1c, because that would be the sensible thing to do. But it would be better if I didn't have to make either assumption. >> >>> I stepped through both the working unit test and the non-working one in order to find >>> differences in the result. What I have found is that, in ssl3_read_n, the call to >>> BIO_read (line 300 in rec_layer_s3.c) returns -1. >>> ret = BIO_read(s->rbio, pkt + len + left, max - left); >>> At this line, pkt is a char[8], len and left = 0 and max = 16717 >> I don't think pkt is a char[8]. It's defined at the top of ssl3_read_n as unsigne char *pkt. >> >> And it had better not be a char[8], since 1) plain char and unsigned char are not the same type, and 2) if max - left is 16717, then you have potential for a massive buffer overflow. >> >>> I'm curious as to why the "data" argument is not a pointer to a buffer, but rather >>> the result of an addition. Maybe my C isnt strong enough... >> It's a pointer into a buffer (specifically, in this case, a pointer to the start of a buffer). In C, adding an integer type to a pointer results in a pointer value. That is, in fact, basic C. >> >> (At least you're only reading C, not writing it. I have in recent days seen C code posted by people who really need to put the language down and back away slowly. C should not be used by people who don't know the language very well.) >> >>> Going even further down the stack, I finally end up at the bottom: >>> static int mem_read(BIO *b, char *out, int outl) >>> ... >>> } else if (bm->length == 0) { >>> ret = b->num; >>> if (ret != 0) >>> BIO_set_retry_read(b); >>> } >>> return ret; >>> At this point, ret = -1... >> So b->num == -1 when you arrived here with bm->length == 0. >> >> The num field is initialized to -1 when a memory BIO is initialized (mem_init in bss_mem.c). And the length is 0, which means there's no data in the BIO. >> >> I don't know (without reading through your code, which I don't have time to do right now) why you're using a memory BIO, or how you've initialized it. It looks like you've simply never put any data into it. >> >> -- >> Michael Wojcik >> Distinguished Engineer, Micro Focus >> >> >> From alexandre.schaff at gmail.com Mon Sep 2 16:49:40 2019 From: alexandre.schaff at gmail.com (Alexandre Schaff) Date: Mon, 2 Sep 2019 18:49:40 +0200 Subject: TLS-1.3 Certificate Authorities implementation and testing Message-ID: Hello, Sorry if question has already been asked, I saw https://github.com/openssl/openssl/issues/3029 . Issue#3029 is a mixed discussion on both tls-1.2 extension "trusted CA indication" (rfc6066#section-6) and TLS-1.3 "Certificate Authorities", thus conclusion is unclear. tests done : openssl version used : openssl-1.1.1a client : "openssl s_client ... -requestCAfile .." ; tls extension in client Hello is present. serverside : 'openssl s_server' using certfile which has 2 root-CA+cert (certA and certB) and keyfile which has both secrets. Whatever the client sends in Certificate Authorities, s_server chooses the first leaf certificate found within certfile. Questions : is rfc8446#section-4.2.4 is not mandatory featuyre of tls-1.3. Does openssl iimplements it fully ? If yes, how to test ? br, Alexandre. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Sep 2 16:59:32 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 2 Sep 2019 12:59:32 -0400 Subject: TLS-1.3 Certificate Authorities implementation and testing In-Reply-To: References: Message-ID: <20190902165932.GH70599@straasha.imrryr.org> On Mon, Sep 02, 2019 at 06:49:40PM +0200, Alexandre Schaff wrote: > serverside : 'openssl s_server' using certfile which has 2 root-CA+cert > (certA and certB) and keyfile which has both secrets. The s_server application loads just one certificate chain from its certFile, and just one key from its keyfile. This happens before any interaction with the TLS client. The test as described is not useful to discern whether or not OpenSSL supports certificate selection based on the client's certificate selection hints. AFAIK, any certificate selection logic needs to go in a suitable callback, since the SSL_CTX can only store one key per algorithm, and so certificate selection requires callbacks to instantiate a per-connection context (as with SNI). So perhaps your answer is that the OpenSSL library does not presently provide built-in facilities for client-hint-based certificate selection, beyond what you get by negotiating a shared signature algorithm. -- Viktor. From roger_no_spam at hotmail.com Tue Sep 3 07:13:57 2019 From: roger_no_spam at hotmail.com (Roger No-Spam) Date: Tue, 3 Sep 2019 07:13:57 +0000 Subject: OPENSSL_armcap_P, OPENSSL_ia32_P, OPENSSL_ppccap_P Message-ID: <4c947b262fe4412bb27942ba41f6bfdfAM0PR06MB424375B5B09F1A1910AFCAB1ACBE0@AM0PR06MB4243.eurprd06.prod.outlook.com> Hi, I'm using openssl on a platform/OS that supports multiple CPU architectures. The context switching does not save SIMD registers unless the thread has a special options set. This creates some challenges when using openssl, which use SIMD registers in several assembler optimizations. I would like to ensure that no assembler optimization can be used if the special option is not set. If the appropriate bits in OPENSSL_armcap_P/OPENSSL_ia32_P/OPENSSL_ppccap_P is disabled, will that guarantee that no instructions using SIMD registers are executed? There is some code within #ifndef __KERNEL__ which indicates that openssl is used in the linux kernel. I believe the linux kernel would have a similar situation regarding SIMD registers. Floating point operations and operations SIMD registers cannot be used in the linux kernel. But I am unable to find any information that confirms that this would cover all code paths. Regards Roger -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger_no_spam at hotmail.com Tue Sep 3 09:54:05 2019 From: roger_no_spam at hotmail.com (Roger No-Spam) Date: Tue, 3 Sep 2019 09:54:05 +0000 Subject: OPENSSL_armcap_P, OPENSSL_ia32_P, OPENSSL_ppccap_P Message-ID: Hi, I'm using openssl on a platform/OS that supports multiple CPU architectures. The context switching does not save SIMD registers unless the thread has a special options set. This creates some challenges when using openssl, which use SIMD registers in several assembler optimizations. I would like to ensure that no assembler optimization can be used if the special option is not set. If the appropriate bits in OPENSSL_armcap_P/OPENSSL_ia32_P/OPENSSL_ppccap_P is disabled, will that guarantee that no instructions using SIMD registers are executed? There is some OPENSSL_XXXcap_P code within #ifndef __KERNEL__ which indicates that openssl is used in the linux kernel. I believe the linux kernel would have a similar situation regarding SIMD registers. Floating point operations and operations SIMD registers cannot be used in the linux kernel. But I am unable to find any information that confirms that this would cover all code paths. Regards Roger -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger_no_spam at hotmail.com Tue Sep 3 09:55:52 2019 From: roger_no_spam at hotmail.com (Roger No-Spam) Date: Tue, 3 Sep 2019 09:55:52 +0000 Subject: OPENSSL_armcap_P, OPENSSL_ia32_P, OPENSSL_ppccap_P Message-ID: Hi, I'm using openssl on a platform/OS that supports multiple CPU architectures. The context switching does not save SIMD registers unless the thread has a special options set. This creates some challenges when using openssl, which use SIMD registers in several assembler optimizations. I would like to ensure that no assembler optimization can be used if the special option is not set. If the appropriate bits in OPENSSL_armcap_P/OPENSSL_ia32_P/OPENSSL_ppccap_P is disabled, will that guarantee that no instructions using SIMD registers are executed? There is some OPENSSL_XXXcap_P code within #ifndef __KERNEL__ which indicates that openssl is used in the linux kernel. I believe the linux kernel would have a similar situation regarding SIMD registers. Floating point operations and operations SIMD registers cannot be used in the linux kernel. But I am unable to find any information that confirms that this would cover all code paths. Regards Roger -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Sep 3 15:38:25 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 3 Sep 2019 11:38:25 -0400 Subject: [TLS] TLSv1.2 - Is zero signature allowed in client CertificateVerify message? In-Reply-To: References: Message-ID: > On Sep 3, 2019, at 11:27 AM, M K Saravanan wrote: > > Thanks Richard for the reply. Let me rephrase my question: > > If a client encounter any error condition (e.g. does not have access to the private key for whatever reason) in generating the signature, can it send zero bytes in the signature field of CertificateVerify message to indicate the error condition? Is this allowed in TLS 1.2 RFC? There is nothing special about an all zero or any other sequence of characters in the signature. A signature is either valid or not. A client that does not possess the private key for its certificate can decline the server's request for a client certificate, by sending a zero-length ClientCertificate and no ClientVerify. -- Viktor. From matt at openssl.org Tue Sep 3 16:19:17 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 3 Sep 2019 17:19:17 +0100 Subject: Forthcoming OpenSSL Releases Message-ID: The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.1.1d, 1.1.0l and 1.0.2t. These releases will be made available on 10th September 2019 between approximately 1200-1600 UTC. These are security fix releases. The highest severity security issue fixed by these releases is rated as LOW. Please note that this is expected to be the last release of 1.1.0 before it goes out of support on 11th September 2019. Yours The OpenSSL Project Team -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From Michael.Wojcik at microfocus.com Tue Sep 3 20:36:08 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 3 Sep 2019 20:36:08 +0000 Subject: Compiling OpenSSL 1.1 - certs directory is empty, how to obtain? In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Pete Cooper > Sent: Saturday, August 24, 2019 13:10 > The `config` and subsequent `make` complete without any visible issues shown. However, > /etc/php/shared/openssl/certs is an empty directory. > Are there OpenSSL compile flags to explicitly build or obtain the current up-to-date > *.pem files for my PHP-only OpenSSL build, or should be looking elsewhere? I haven't seen a response to this on the list. OpenSSL does not include a collection of trusted certificates. You need to get them from some other source. You may copy them from your OS distribution, for example. Another popular source is the Mozilla certificate collection. Adam Langley wrote a Go program that converts the Mozilla collection to PEM and excludes those marked as untrusted; you can find it at: https://github.com/agl/extract-nss-root-certs (And Go itself is available from https://golang.org, of course, if you don't have that installed.) There are many opinions about what constitutes a good collection of trust anchors for various applications. Some people feel the collections provided with most OS and browser distributions are too generous, and saccrifice security for interoperability. If you're going to assemble a set of trust anchors that includes public CAs, it may be a good idea to familiarize yourself with the issues. Ivan Ristic's /Bulletproof SSL and TLS/ (available at https://feistyduck.com) has a good survey. -- Michael Wojcik Distinguished Engineer, Micro Focus From stephen.farrell at cs.tcd.ie Wed Sep 4 12:42:18 2019 From: stephen.farrell at cs.tcd.ie (Stephen Farrell) Date: Wed, 4 Sep 2019 13:42:18 +0100 Subject: early openssl and curl forks that support ESNI Message-ID: <87d30d16-25bf-7a54-099f-41d861abe1f7@cs.tcd.ie> Hiya, We've done some work on an openssl fork [1] that has ESNI support and on a curl fork [2] that uses that. It's early days, but if anyone wants to try play with the build and give us feedback that'd be great. There's a HOWTO at [3]. If you find any issues with that you'd like to raise then please raise an issue at [1] or [2], or send mail. Thanks, Stephen. [1] https://github.com/sftcd/openssl/tree/master/esnistuff [2] https://github.com/niallor/curl [3] https://defo.ie/building-curl-openssl-with-esni.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x5AB2FAF17B172BEA.asc Type: application/pgp-keys Size: 10715 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 dclarke at blastwave.org Thu Sep 5 06:15:22 2019 From: dclarke at blastwave.org (Dennis Clarke) Date: Thu, 5 Sep 2019 02:15:22 -0400 Subject: Forthcoming OpenSSL Releases In-Reply-To: References: Message-ID: <1e3694f2-531d-e48c-2a60-7ebcb10e6c04@blastwave.org> On 9/3/19 12:19 PM, Matt Caswell wrote: > The OpenSSL project team would like to announce the forthcoming release > of OpenSSL versions 1.1.1d, 1.1.0l and 1.0.2t. > > These releases will be made available on 10th September 2019 between > approximately 1200-1600 UTC. > > These are security fix releases. The highest severity security issue fixed by > these releases is rated as LOW. > > Please note that this is expected to be the last release of 1.1.0 before it goes > out of support on 11th September 2019. > > Yours > > The OpenSSL Project Team > Will there be pre-release tarballs somewhere similar to https://www.openssl.org/source/snapshot/ ? Dennis Clarke From jgh at wizmail.org Sun Sep 8 17:09:12 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Sun, 8 Sep 2019 18:09:12 +0100 Subject: SSL_get_certificate In-Reply-To: <50968caa-f7a5-5632-d074-a2d66f66f914@wizmail.org> References: <50968caa-f7a5-5632-d074-a2d66f66f914@wizmail.org> Message-ID: <3d8625de-319a-827e-968d-b89fd40c02d3@wizmail.org> On 29/08/2019 23:31, Jeremy Harris wrote: > I have a note from 2017 in my code to the effect that > SSL_get_certificate() is broken in that it returns the last > cert loaded rather than the one passed out to the client > (on the server). Note that one might have both an EC and an RSA cert loaded. > Is this still the case? I can't track down any obvious fix in the > OpenSSL git. Nobody knows? -- Cheers, Jeremy From openssl-users at dukhovni.org Mon Sep 9 15:21:24 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 9 Sep 2019 11:21:24 -0400 Subject: SSL_get_certificate In-Reply-To: <3d8625de-319a-827e-968d-b89fd40c02d3@wizmail.org> References: <50968caa-f7a5-5632-d074-a2d66f66f914@wizmail.org> <3d8625de-319a-827e-968d-b89fd40c02d3@wizmail.org> Message-ID: <526EEF97-EEF7-4E7D-BF14-81A6147EFCE1@dukhovni.org> > On Sep 8, 2019, at 1:09 PM, Jeremy Harris wrote: > >> I have a note from 2017 in my code to the effect that >> SSL_get_certificate() is broken in that it returns the last >> cert loaded rather than the one passed out to the client >> (on the server). > > Note that one might have both an EC and an RSA cert loaded. One of the "CHANGES" entries for 1.0.1d reads: *) Call OCSP Stapling callback after ciphersuite has been chosen, so the right response is stapled. Also change SSL_get_certificate() so it returns the certificate actually sent. See http://rt.openssl.org/Ticket/Display.html?id=2836. [Rob Stradling ] Consequently 1.0.1d and later had the expected behaviour. However, in commits this was updated: dc144417571735c82853421a8845ef603d828a0b (1.0.2-beta1) e5db9c3b67deb80e274f66e3832a9cfba931670c (also master, at the time 1.1.0-dev) Minor enhancement to PR#2836 fix. Instead of modifying SSL_get_certificate change the current certificate (in s->cert->key) to the one used and then SSL_get_certificate and SSL_get_privatekey will automatically work. The code for "change the current certificate" was: diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c index d0764e8cd3..a438321a41 100644 --- a/ssl/t1_lib.c +++ b/ssl/t1_lib.c @@ -2355,6 +2355,18 @@ int ssl_check_clienthello_tlsext_late(SSL *s) if ((s->tlsext_status_type != -1) && s->ctx && s->ctx->tlsext_status_cb) { int r; + CERT_PKEY *certpkey; + certpkey = ssl_get_server_send_pkey(s); + /* If no certificate can't return certificate status */ + if (certpkey == NULL) + { + s->tlsext_status_expected = 0; + return 1; + } + /* Set current certificate to one we will use so + * SSL_get_certificate et al can pick it up. + */ + s->cert->key = certpkey; But it only runs if there's a "tlsext_status_cb" callback, which may not cover all the expected use-cases. I think this merits a new issue on Github. On servers the function should return the certificate used, whether that happened via an SNI callback, or simply via choosing a certificate for the negotiated algorithm... >> Is this still the case? I can't track down any obvious fix in the >> OpenSSL git. > > Nobody knows? Perhaps I do now... -- Viktor. From rsalz at akamai.com Mon Sep 9 16:53:56 2019 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 9 Sep 2019 16:53:56 +0000 Subject: Compiling OpenSSL 1.1 - certs directory is empty, how to obtain? In-Reply-To: References: Message-ID: <809EFDB4-395D-4FD7-BD71-0920476E0595@akamai.com> Another great source is https://github.com/nabla-c0d3/trust_stores_observatory One-stop shopping for all of apple, Android, Windows, NSS, OpenJDK, Oracle Java. From ndambra2 at gmail.com Mon Sep 9 18:56:26 2019 From: ndambra2 at gmail.com (Nikki D'Ambra) Date: Mon, 9 Sep 2019 14:56:26 -0400 Subject: Openssl-1.0.2t availability Message-ID: Hello, I was wondering when the latest version openssl, version 1.0.2t will be available for public download? Thank you, Nikki -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Mon Sep 9 19:23:35 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 9 Sep 2019 21:23:35 +0200 Subject: Openssl-1.0.2t availability In-Reply-To: References: Message-ID: <09757247-de10-615b-2c93-2cc3e7dfb47c@wisemo.com> On 09/09/2019 20:56, Nikki D'Ambra wrote: > Hello, > > I was wondering when the latest version openssl, version 1.0.2t will > be available for public download? > Announcement is 2019-09-10 between 12:00 and 16:00 UTC approximately.? That's about 17 to 21 hours after your question. 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 matt at openssl.org Tue Sep 10 16:16:50 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 10 Sep 2019 17:16:50 +0100 Subject: Forthcoming OpenSSL Releases In-Reply-To: References: Message-ID: <071f6901-1706-9c23-e626-3c11d19615ab@openssl.org> On 03/09/2019 17:19, Matt Caswell wrote: > The OpenSSL project team would like to announce the forthcoming release > of OpenSSL versions 1.1.1d, 1.1.0l and 1.0.2t. > > These releases will be made available on 10th September 2019 between > approximately 1200-1600 UTC. > > These are security fix releases. The highest severity security issue fixed by > these releases is rated as LOW. > > Please note that this is expected to be the last release of 1.1.0 before it goes > out of support on 11th September 2019. We have encountered some technical problems pushing these releases onto the website today. Until those are resolved the release tarballs are not visible via the standard links. The releases are temporarily available at this non-standard location: https://www.openssl.org/source/? You can download them directly from there until such time as we fix the website. We will send out the normal release announcements as soon as everything is working normally again. Regards Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From openssl at openssl.org Tue Sep 10 16:18:55 2019 From: openssl at openssl.org (OpenSSL) Date: Tue, 10 Sep 2019 16:18:55 +0000 Subject: OpenSSL Security Advisory Message-ID: <20190910161855.GA17572@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL Security Advisory [10 September 2019] ============================================= ECDSA remote timing attack (CVE-2019-1547) ========================================== Severity: Low Normally in OpenSSL EC groups always have a co-factor present and this is used in side channel resistant code paths. However, in some cases, it is possible to construct a group using explicit parameters (instead of using a named curve). In those cases it is possible that such a group does not have the cofactor present. This can occur even where all the parameters match a known named curve. If such a curve is used then OpenSSL falls back to non-side channel resistant code paths which may result in full key recovery during an ECDSA signature operation. In order to be vulnerable an attacker would have to have the ability to time the creation of a large number of signatures where explicit parameters with no co-factor present are in use by an application using libcrypto. For the avoidance of doubt libssl is not vulnerable because explicit parameters are never used. OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue. OpenSSL 1.1.1 users should upgrade to 1.1.1d OpenSSL 1.1.0 users should upgrade to 1.1.0l OpenSSL 1.0.2 users should upgrade to 1.0.2t This issue was reported by Cesar Pereida Garc?a, Sohaib ul Hassan, Nicola Tuveri, Iaroslav Gridin, Alejandro Cabrera Aldaya, and Billy Brumley. The fix was developed by Billy Brumley. It was reported to OpenSSL on 5th August 2019. Fork Protection (CVE-2019-1549) =============================== Severity: Low OpenSSL 1.1.1 introduced a rewritten random number generator (RNG). This was intended to include protection in the event of a fork() system call in order to ensure that the parent and child processes did not share the same RNG state. However this protection was not being used in the default case. A partial mitigation for this issue is that the output from a high precision timer is mixed into the RNG state so the likelihood of a parent and child process sharing state is significantly reduced. If an application already calls OPENSSL_init_crypto() explicitly using OPENSSL_INIT_ATFORK then this problem does not occur at all. OpenSSL version 1.1.1 is affected by this issue. OpenSSL 1.1.1 users should upgrade to 1.1.1d This issue was reported by Matt Caswell. The fix was developed by Matthias St. Pierre. It was reported to OpenSSL on 27th May 2019. Padding Oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey (CVE-2019-1563) ============================================================================ Severity: Low In situations where an attacker receives automated notification of the success or failure of a decryption attempt an attacker, after sending a very large number of messages to be decrypted, can recover a CMS/PKCS7 transported encryption key or decrypt any RSA encrypted message that was encrypted with the public RSA key, using a Bleichenbacher padding oracle attack. Applications are not affected if they use a certificate together with the private RSA key to the CMS_decrypt or PKCS7_decrypt functions to select the correct recipient info to decrypt. OpenSSL 1.1.1 users should upgrade to 1.1.1d OpenSSL 1.1.0 users should upgrade to 1.1.0l OpenSSL 1.0.2 users should upgrade to 1.0.2t This issue was reported by and the fix developed by Bernd Edlinger. It was reported to OpenSSL on 21st August 2019. Note ===== OpenSSL 1.0.2 is currently only receiving security updates. Support for 1.0.2 will end on 31st December 2019. Support for 1.1.0 ends on 11th September 2019 so 1.1.0l is expected to be the last 1.1.0 release. Users of these versions should upgrade to OpenSSL 1.1.1. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20190910.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl13vK0ACgkQ2cTSbQ5g RJGJIgf+Me900bLV9TrVDWvNRQbuRe0tOPPhP59J4tJAJiRZ1GG0JV2YITQynjTP hrz9mvajgWbkGYlTZmPVFOdJr7LKbrUrxk7shEfXqmiiCLG8tHYiCe3PF+/Cy7gA X1vY9CDfv//3VSqOLM9RM3CCcWAAv3KeP851X0PgCiMVvGAJbYOu3bmB+KsEKFzm fWRDabUMbl1KCSgCIvvlNv0bKR/GfpW3cWruUvG0sfjyPWwS+yn8z0T3/ibFJqkb Cmuqa3/kC9uZg8AhiODR+nz6D1mC2UiNZ2Wa/XO6O68rO/y3ZKbaiMGLze1qJep5 3PnybOw8b3JvpVRFYw09YwgLObBX8w== =8bP1 -----END PGP SIGNATURE----- From chitrang.srivastava at gmail.com Wed Sep 11 10:31:15 2019 From: chitrang.srivastava at gmail.com (Chitrang Srivastava) Date: Wed, 11 Sep 2019 16:01:15 +0530 Subject: PrivateKey Decrypt Failure Message-ID: Hi, I am using openssl 1.1.1b and I am storing private key encrypted. I am storing private key as *PEM_write_bio_PrivateKey*(bio, pkey, EVP_aes_128_cbc(), PKeyPassPKCS12, 0, 0, NULL); and on system startup reading using the following way if(!*PEM_read_bio_PrivateKey*(keyBIO, &user_s_key, NULL, decryptSharedSecret)) Upon debugging I found it is failing in PKCS12_pbe_crypt > *EVP_CipherFinal_ex* Please suggest where I am doing wrong? Could this be appear to related to padding ? Without encryption of key , it works fine , which clear other code is all fine. Thanks, *evp_enc.c:EVP_DecryptFinal_ex:569* /* * The following assumes that the ciphertext has been authenticated. * Otherwise it provides a padding oracle. */ n = ctx->final[b - 1]; if (n == 0 || n > (int)b) { * EVPerr(EVP_F_EVP_DECRYPTFINAL_EX, EVP_R_BAD_DECRYPT);* return 0; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Wed Sep 11 15:23:15 2019 From: openssl at openssl.org (OpenSSL) Date: Wed, 11 Sep 2019 15:23:15 +0000 Subject: OpenSSL version 1.0.2t published Message-ID: <20190911152315.GA21928@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.0.2t released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2t of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2t is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2t.tar.gz Size: 5355422 SHA1 checksum: 8ac3fd379cf8c8ef570abb51ec52a88fd526f88a SHA256 checksum: 14cb464efe7ac6b54799b34456bd69558a749a4931ecfd9cf9f71d7881cac7bc The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2t.tar.gz openssl sha256 openssl-1.0.2t.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl13pssACgkQ2cTSbQ5g RJFr9wf/X0fke/exS13hQb4h9RqE9fYouVbSNKTKhLp9X8BtYUOtUTjO5ispKt+1 BGWBotApoXBTopOsdJVXhzLtYst2YdKEtvyJAEFyxfpJa2PL4jmo5zxk93qWjDjA u0HXR1Tu4XTLlE3EfqbfV/8bVO4kntTCk/xvg0gql1LUCVIRtjmqmsKOe7MJAHkH 94yb3kRFMpXb2YB6/zrK+ZuruL5ejTZCcXG7Dx9+LH5X7E/8KFDknk0Zo6w6970I LbrXjtAOfHtVEK5XAFESCkMkjNqahopOs90AtemiOt1oOsNztjr7bVFHqJ3/oBMf OYamiO1W2IhyxnPbet6zUDYG0FtYpw== =sBvh -----END PGP SIGNATURE----- From openssl at openssl.org Wed Sep 11 15:23:33 2019 From: openssl at openssl.org (OpenSSL) Date: Wed, 11 Sep 2019 15:23:33 +0000 Subject: OpenSSL version 1.1.0l published Message-ID: <20190911152333.GA21951@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.1.0l 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.0l of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.0-notes.html OpenSSL 1.1.0l 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.0l.tar.gz Size: 5294857 SHA1 checksum: 6e3507b29e2630f56023887d1f7d7ba1f584819b SHA256 checksum: 74a2f756c64fd7386a29184dc0344f4831192d61dc2481a93a4c5dd727f41148 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0l.tar.gz openssl sha256 openssl-1.1.0l.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl13okkACgkQ2cTSbQ5g RJFu5wf9HCvluEc1W1UwNqaw48n3g1ZclRdexYFO12HtUTTtriUwu0BPorvzHVmo x4I0JzUxLeRXyS2kdBBPJC0OlPlrZMkWfwNy9IF2BRFGcMuGhjIOu60FfRNkGOM8 63RdIuSy1oPnwL4kUOdQi4pru1UcQVx25l4tpB6pLMKKgioGc1x75mP+C/lxhM16 PvPSo8pETU60V2QFaxzbfOqbS8LJhbO2m+dYCzgGy6Rjrd2CyzyZbtKC/bWoyMhW s3jQ4oBjGh28y/mrzLup9oXP4f4/GlWajxd+pFXsj8xRfwEN7Zwg7eLlg6uZh6Cq 4KhsFKHIKgvba/lekhASdh71BdVVSA== =na1Q -----END PGP SIGNATURE----- From openssl at openssl.org Wed Sep 11 15:23:50 2019 From: openssl at openssl.org (OpenSSL) Date: Wed, 11 Sep 2019 15:23:50 +0000 Subject: OpenSSL version 1.1.1d published Message-ID: <20190911152350.GA22068@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.1.1d 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.1d 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.1d 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.1d.tar.gz Size: 8845861 SHA1 checksum: 056057782325134b76d1931c48f2c7e6595d7ef4 SHA256 checksum: 1e3a91bc1f9dfce01af26026f856e064eab4c8ee0a8f457b5ae30b40b8b711f2 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1d.tar.gz openssl sha256 openssl-1.1.1d.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl13oWoACgkQ2cTSbQ5g RJFGjwf+IA34TBZZt/lwjtsALggJuoRrYyCBCDbdwJA+rBO2uQV2h+f7Tj5FBcuI ARRhbUJqCDq7MFl1+6O5jPhTxZK0P1z242rOTvW50w4MFy+FZCwZjloxRBtgOlTy y4t7yzuvCU1RidKiK9B42a6KypgQFEEHSlCkepNAjX94OLQhB+iF20vJ86gSFzrv keJTUDXEbAa7I9MyK9p7SQbqHgFbTt0QAIYj/afNGOGv6ZyjiVrbp+4I29I0IG98 Dn4+4dp0xaY+oC1FTyO+lqfTLXuSnVR8TGDACHFyeQHCjf6wfSbFlxfH40CfeQzv 8vakK0+YhIAij7Pcm4te9ffUaSeNHg== =jsdh -----END PGP SIGNATURE----- From brunni at netestate.de Wed Sep 11 15:48:01 2019 From: brunni at netestate.de (Michael Brunnbauer) Date: Wed, 11 Sep 2019 17:48:01 +0200 Subject: Support for /dev/*random in OpenSSL 1.1.1 Message-ID: <20190911154801.GA22939@netestate.de> hi all, I have glibc 2.30 with Kernel 4.9.191 but unfortunately I compiled glibc with old Kernel headers from Linux 3.16.46. It seems that as a result of this, my getrandom() and getentropy() are stubs that always fail with ENOSYS. This leads to: ./util/shlib_wrap.sh apps/openssl rand -hex 10 4145686272:error:2406C06E:random number generator:RAND_DRBG_instantiate:error retrieving entropy:crypto/rand/drbg_lib.c:342: ... Fine I thought, supply --with-rand-seed=devrandom to Configure and be done with it until you can fix your glibc. Nope - same result. Now I see this in e_os.h: /* * Linux kernels 4.8 and later changes how their random device works and there * is no reliable way to tell that /dev/urandom has been seeded -- getentropy(2) * should be used instead. */ # ifndef DEVRANDOM_SAFE_KERNEL # define DEVRANDOM_SAFE_KERNEL 4, 8 # endif So openSSL 1.1.1 will not support /dev/*random with Kernels > 4.8 ? I can fix the kernel headers before compiling the next release of glibc but this is some months away. Is there anything I can do now? I don't like the idea to recompile glibc - Version upgrades are much easier to deploy than replacing the current version. Regards, Michael Brunnbauer -- ++ Michael Brunnbauer ++ netEstate GmbH ++ Geisenhausener Stra?e 11a ++ 81379 M?nchen ++ Tel +49 89 32 19 77 80 ++ Fax +49 89 32 19 77 89 ++ E-Mail brunni at netestate.de ++ https://www.netestate.de/ ++ ++ Sitz: M?nchen, HRB Nr.142452 (Handelsregister B M?nchen) ++ USt-IdNr. DE221033342 ++ Gesch?ftsf?hrer: Michael Brunnbauer, Franz Brunnbauer ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From wiml at omnigroup.com Wed Sep 11 17:27:45 2019 From: wiml at omnigroup.com (Wim Lewis) Date: Wed, 11 Sep 2019 10:27:45 -0700 Subject: PrivateKey Decrypt Failure References: <36495C85-7F6B-4529-B07B-2363E230F10D@omnigroup.com> Message-ID: On Sep 11, 2019, at 3:31 AM, Chitrang Srivastava wrote: > I am using openssl 1.1.1b and I am storing private key encrypted. > > I am storing private key as > PEM_write_bio_PrivateKey(bio, pkey, EVP_aes_128_cbc(), PKeyPassPKCS12, 0, 0, NULL); I don't think that PEM_write_bio_PrivateKey() will compute the key length for you if you pass 0. If you pass klen=0 it will encrypt with a 0-byte key. Try passing strlen(PKeyPassPKCS12) for klen and see if that helps. From Carl.Tietjen at microfocus.com Wed Sep 11 17:08:54 2019 From: Carl.Tietjen at microfocus.com (Carl Tietjen) Date: Wed, 11 Sep 2019 17:08:54 +0000 Subject: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc In-Reply-To: References: Message-ID: Hello, >From the download site, https://www.openssl.org/source/ click the SHA256 link for the new releases. The files do not contain SHA256 hashes. FYI -- The SHA1 hashes seem to be ok -- I only checked one. Thanks, Carl -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Sep 11 18:10:22 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 11 Sep 2019 19:10:22 +0100 Subject: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc In-Reply-To: References: Message-ID: <7a0ad1fd-093c-56bb-8764-f824eb74c499@openssl.org> On 11/09/2019 18:08, Carl Tietjen wrote: > Hello, > > From the download site, https://www.openssl.org/source/ click the SHA256 link > for the new releases.? The files do not contain SHA256 hashes. > > FYI -- The SHA1 hashes seem to be ok -- I only checked one. These seem to be ok for me? Matt From Carl.Tietjen at microfocus.com Wed Sep 11 19:25:32 2019 From: Carl.Tietjen at microfocus.com (Carl Tietjen) Date: Wed, 11 Sep 2019 19:25:32 +0000 Subject: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc In-Reply-To: <7a0ad1fd-093c-56bb-8764-f824eb74c499@openssl.org> References: <7a0ad1fd-093c-56bb-8764-f824eb74c499@openssl.org> Message-ID: Weird. -- When I switch to download with Chrome, the files are fine. -- I retested using my default browser (Firefox) and I am still seeing the issue. -- I tried it with IE and also see the issue. Can you verify the Firefox and IE downloads. Carl -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Wednesday, September 11, 2019 11:10 AM To: openssl-users at openssl.org Subject: Re: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc On 11/09/2019 18:08, Carl Tietjen wrote: > Hello, > > From the download site, https://www.openssl.org/source/ click the > SHA256 link for the new releases. The files do not contain SHA256 hashes. > > FYI -- The SHA1 hashes seem to be ok -- I only checked one. These seem to be ok for me? Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Wed Sep 11 20:04:53 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 11 Sep 2019 20:04:53 +0000 Subject: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc In-Reply-To: References: <7a0ad1fd-093c-56bb-8764-f824eb74c499@openssl.org> Message-ID: I can confirm Carl's issue when I download using Pale Moon (a Firefox fork): ----- $ file openssl-1.1.1d.tar.gz.sha256 openssl-1.1.1d.tar.gz.sha256: gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT) $ file openssl-1.1.1d.tar.gz.sha1 openssl-1.1.1d.tar.gz.sha1: ASCII text $ file openssl-1.1.1d.tar.gz.asc openssl-1.1.1d.tar.gz.asc: PGP signature Signature (old) $ gpg --verify openssl-1.1.1d.tar.gz.asc openssl-1.1.1d.tar.gz gpg: Signature made 09/10/19 09:13:14 EDT using RSA key ID 0E604491 gpg: Good signature from "Matt Caswell " [full] gpg: aka "Matt Caswell " [full] ----- So the .sha1 file and the signature look fine, but the .sha256 file is apparently a fragment of gzip-compressed data. And ... let's see ... gunzip'ing it gives us the SHA256 hash in ASCII. So my guess the server is gzip'ing it (or it's gzip'ed at rest on the server), but the server isn't setting the content-transfer-encoding correctly. Chrome might be content-sniffing and decompressing based on that. I haven't looked at the response headers though. (Personally, I always check the signature and don't bother with the posted hashes.) -- Michael Wojcik Distinguished Engineer, Micro Focus From paul.dale at oracle.com Wed Sep 11 21:25:29 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Thu, 12 Sep 2019 07:25:29 +1000 Subject: Support for /dev/*random in OpenSSL 1.1.1 In-Reply-To: <20190911154801.GA22939@netestate.de> References: <20190911154801.GA22939@netestate.de> Message-ID: <0EC889BB-E5F5-441D-9C40-461895AF02A5@oracle.com> As a temporary workaround, you might try defining __NR_getrandom to the appropriate system call number, although it looks like the extra efforts to get past the other preprocessor check ing rand_unit.c could get ugly. What about defining your our getrandom function in your application that calls the system call? The linker should find that before glibc?s. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 12 Sep 2019, at 1:48 am, Michael Brunnbauer wrote: > > > hi all, > > I have glibc 2.30 with Kernel 4.9.191 but unfortunately I compiled glibc with > old Kernel headers from Linux 3.16.46. It seems that as a result of this, my > getrandom() and getentropy() are stubs that always fail with ENOSYS. This > leads to: > > ./util/shlib_wrap.sh apps/openssl rand -hex 10 > 4145686272:error:2406C06E:random number generator:RAND_DRBG_instantiate:error retrieving entropy:crypto/rand/drbg_lib.c:342: > ... > > Fine I thought, supply --with-rand-seed=devrandom to Configure and be done > with it until you can fix your glibc. Nope - same result. > > Now I see this in e_os.h: > > /* > * Linux kernels 4.8 and later changes how their random device works and there > * is no reliable way to tell that /dev/urandom has been seeded -- getentropy(2) > * should be used instead. > */ > # ifndef DEVRANDOM_SAFE_KERNEL > # define DEVRANDOM_SAFE_KERNEL 4, 8 > # endif > > So openSSL 1.1.1 will not support /dev/*random with Kernels > 4.8 ? > > I can fix the kernel headers before compiling the next release of glibc but > this is some months away. > > Is there anything I can do now? I don't like the idea to recompile glibc - > Version upgrades are much easier to deploy than replacing the current version. > > Regards, > > Michael Brunnbauer > > -- > ++ Michael Brunnbauer > ++ netEstate GmbH > ++ Geisenhausener Stra?e 11a > ++ 81379 M?nchen > ++ Tel +49 89 32 19 77 80 > ++ Fax +49 89 32 19 77 89 > ++ E-Mail brunni at netestate.de > ++ https://www.netestate.de/ > ++ > ++ Sitz: M?nchen, HRB Nr.142452 (Handelsregister B M?nchen) > ++ USt-IdNr. DE221033342 > ++ Gesch?ftsf?hrer: Michael Brunnbauer, Franz Brunnbauer > ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Wed Sep 11 21:40:52 2019 From: levitte at openssl.org (Richard Levitte) Date: Wed, 11 Sep 2019 23:40:52 +0200 Subject: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc In-Reply-To: References: <7a0ad1fd-093c-56bb-8764-f824eb74c499@openssl.org> Message-ID: <871rwma4uz.wl-levitte@openssl.org> Issue found... Apache detected .gz in the file name and set the encoding to 'application/x-gzip'... Apparently, we already force .asc and .sha1 files to application/binary, but have apparently not added a similar directive for .sha256 files. Now done. Cheers, Richard On Wed, 11 Sep 2019 22:04:53 +0200, Michael Wojcik wrote: > > I can confirm Carl's issue when I download using Pale Moon (a Firefox fork): > > ----- > $ file openssl-1.1.1d.tar.gz.sha256 > openssl-1.1.1d.tar.gz.sha256: gzip compressed data, from FAT filesystem (MS-DOS, > OS/2, NT) > > $ file openssl-1.1.1d.tar.gz.sha1 > openssl-1.1.1d.tar.gz.sha1: ASCII text > > $ file openssl-1.1.1d.tar.gz.asc > openssl-1.1.1d.tar.gz.asc: PGP signature Signature (old) > > $ gpg --verify openssl-1.1.1d.tar.gz.asc openssl-1.1.1d.tar.gz > gpg: Signature made 09/10/19 09:13:14 EDT using RSA key ID 0E604491 > gpg: Good signature from "Matt Caswell " [full] > gpg: aka "Matt Caswell " [full] > ----- > > So the .sha1 file and the signature look fine, but the .sha256 file is apparently a fragment of gzip-compressed data. And ... let's see ... gunzip'ing it gives us the SHA256 hash in ASCII. So my guess the server is gzip'ing it (or it's gzip'ed at rest on the server), but the server isn't setting the content-transfer-encoding correctly. Chrome might be content-sniffing and decompressing based on that. I haven't looked at the response headers though. > > (Personally, I always check the signature and don't bother with the posted hashes.) > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From Carl.Tietjen at microfocus.com Wed Sep 11 22:25:40 2019 From: Carl.Tietjen at microfocus.com (Carl Tietjen) Date: Wed, 11 Sep 2019 22:25:40 +0000 Subject: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc In-Reply-To: <871rwma4uz.wl-levitte@openssl.org> References: <7a0ad1fd-093c-56bb-8764-f824eb74c499@openssl.org> <871rwma4uz.wl-levitte@openssl.org> Message-ID: Still seeing the issue for SOME of the SHA256 files... I waited for a while thinking it might be a cache issue, but no change. https://www.openssl.org/source/openssl-1.0.2t.tar.gz.sha256 -- BAD https://www.openssl.org/source/openssl-1.1.0l.tar.gz.sha256 -- OK https://www.openssl.org/source/openssl-1.1.1d.tar.gz.sha256 -- BAD https://www.openssl.org/source/openssl-fips-2.0.16.tar.gz.sha256 -- OK https://www.openssl.org/source/openssl-fips-ecp-2.0.16.tar.gz.sha256 -- OK -----Original Message----- From: Richard Levitte [mailto:levitte at openssl.org] Sent: Wednesday, September 11, 2019 2:41 PM To: Michael Wojcik Cc: Carl Tietjen ; Matt Caswell ; openssl-users at openssl.org Subject: Re: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc Issue found... Apache detected .gz in the file name and set the encoding to 'application/x-gzip'... Apparently, we already force .asc and .sha1 files to application/binary, but have apparently not added a similar directive for .sha256 files. Now done. Cheers, Richard On Wed, 11 Sep 2019 22:04:53 +0200, Michael Wojcik wrote: > > I can confirm Carl's issue when I download using Pale Moon (a Firefox fork): > > ----- > $ file openssl-1.1.1d.tar.gz.sha256 > openssl-1.1.1d.tar.gz.sha256: gzip compressed data, from FAT > filesystem (MS-DOS, OS/2, NT) > > $ file openssl-1.1.1d.tar.gz.sha1 > openssl-1.1.1d.tar.gz.sha1: ASCII text > > $ file openssl-1.1.1d.tar.gz.asc > openssl-1.1.1d.tar.gz.asc: PGP signature Signature (old) > > $ gpg --verify openssl-1.1.1d.tar.gz.asc openssl-1.1.1d.tar.gz > gpg: Signature made 09/10/19 09:13:14 EDT using RSA key ID 0E604491 > gpg: Good signature from "Matt Caswell >" [full] > gpg: aka "Matt Caswell >" [full] > ----- > > So the .sha1 file and the signature look fine, but the .sha256 file is apparently a fragment of gzip-compressed data. And ... let's see ... gunzip'ing it gives us the SHA256 hash in ASCII. So my guess the server is gzip'ing it (or it's gzip'ed at rest on the server), but the server isn't setting the content-transfer-encoding correctly. Chrome might be content-sniffing and decompressing based on that. I haven't looked at the response headers though. > > (Personally, I always check the signature and don't bother with the > posted hashes.) > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Wed Sep 11 23:40:46 2019 From: levitte at openssl.org (Richard Levitte) Date: Thu, 12 Sep 2019 01:40:46 +0200 Subject: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc In-Reply-To: References: <7a0ad1fd-093c-56bb-8764-f824eb74c499@openssl.org> <871rwma4uz.wl-levitte@openssl.org> Message-ID: <87zhja8kqp.wl-levitte@openssl.org> Thanks for the heads up. For some reason, the information at our CDN remained incorrect for the "BAD" files, so I purged all the current release files there, so their cache for them would rebuild from scratch. They look better now. Cheers, Richard On Thu, 12 Sep 2019 00:25:40 +0200, Carl Tietjen wrote: > > > Still seeing the issue for SOME of the SHA256 files... I waited for a while thinking it might be > a cache issue, but no change. > > https://www.openssl.org/source/openssl-1.0.2t.tar.gz.sha256 -- BAD > > https://www.openssl.org/source/openssl-1.1.0l.tar.gz.sha256 -- OK > > https://www.openssl.org/source/openssl-1.1.1d.tar.gz.sha256 -- BAD > > https://www.openssl.org/source/openssl-fips-2.0.16.tar.gz.sha256 -- OK > > https://www.openssl.org/source/openssl-fips-ecp-2.0.16.tar.gz.sha256 -- OK > > -----Original Message----- > From: Richard Levitte [mailto:levitte at openssl.org] > Sent: Wednesday, September 11, 2019 2:41 PM > To: Michael Wojcik > Cc: Carl Tietjen ; Matt Caswell ; > openssl-users at openssl.org > Subject: Re: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, > 1.0.2t, 1.1.0l etc > > Issue found... Apache detected .gz in the file name and set the encoding to 'application/ > x-gzip'... Apparently, we already force .asc and .sha1 files to application/binary, but have > apparently not added a similar directive for .sha256 files. > > Now done. > > Cheers, > > Richard > > On Wed, 11 Sep 2019 22:04:53 +0200, > > Michael Wojcik wrote: > > > > > > I can confirm Carl's issue when I download using Pale Moon (a Firefox fork): > > > > > > ----- > > > $ file openssl-1.1.1d.tar.gz.sha256 > > > openssl-1.1.1d.tar.gz.sha256: gzip compressed data, from FAT > > > filesystem (MS-DOS, OS/2, NT) > > > > > > $ file openssl-1.1.1d.tar.gz.sha1 > > > openssl-1.1.1d.tar.gz.sha1: ASCII text > > > > > > $ file openssl-1.1.1d.tar.gz.asc > > > openssl-1.1.1d.tar.gz.asc: PGP signature Signature (old) > > > > > > $ gpg --verify openssl-1.1.1d.tar.gz.asc openssl-1.1.1d.tar.gz > > > gpg: Signature made 09/10/19 09:13:14 EDT using RSA key ID 0E604491 > > > gpg: Good signature from "Matt Caswell " [full] > > > gpg: aka "Matt Caswell " [full] > > > ----- > > > > > > So the .sha1 file and the signature look fine, but the .sha256 file is apparently a fragment of > gzip-compressed data. And ... let's see ... gunzip'ing it gives us the SHA256 hash in ASCII. So my > guess the server is gzip'ing it (or it's gzip'ed at rest on the server), but the server isn't > setting the content-transfer-encoding correctly. Chrome might be content-sniffing and > decompressing based on that. I haven't looked at the response headers though. > > > > > > (Personally, I always check the signature and don't bother with the > > > posted hashes.) > > > > > > -- > > > Michael Wojcik > > > Distinguished Engineer, Micro Focus > > > > > > > > -- > > Richard Levitte levitte at openssl.org > > OpenSSL Project http://www.openssl.org/~levitte/ > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From chitrang.srivastava at gmail.com Thu Sep 12 05:49:07 2019 From: chitrang.srivastava at gmail.com (Chitrang Srivastava) Date: Thu, 12 Sep 2019 11:19:07 +0530 Subject: PrivateKey Decrypt Failure In-Reply-To: <36495C85-7F6B-4529-B07B-2363E230F10D@omnigroup.com> References: <36495C85-7F6B-4529-B07B-2363E230F10D@omnigroup.com> Message-ID: Thanks very much, that worked. On Wed, Sep 11, 2019 at 10:56 PM Wim Lewis wrote: > > > On Sep 11, 2019, at 3:31 AM, Chitrang Srivastava < > chitrang.srivastava at gmail.com> wrote: > > I am using openssl 1.1.1b and I am storing private key encrypted. > > > > I am storing private key as > > PEM_write_bio_PrivateKey(bio, pkey, EVP_aes_128_cbc(), PKeyPassPKCS12, > 0, 0, NULL); > > I don't think that PEM_write_bio_PrivateKey() will compute the key length > for you if you pass 0. If you pass klen=0 it will encrypt with a 0-byte > key. Try passing strlen(PKeyPassPKCS12) for klen and see if that helps. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From barati.j.prasad at gmail.com Thu Sep 12 07:50:23 2019 From: barati.j.prasad at gmail.com (Bharathi Prasad) Date: Thu, 12 Sep 2019 00:50:23 -0700 (MST) Subject: CSR with only public key Message-ID: <1568274623649-0.post@n7.nabble.com> Hi, I have the public key of the client but not the private key. I am required to generate a CSR with only public key. I understand private key is required for Proof of Possession. However, as per my requirement I am supposed to create CSR only with public key and my CA would create a certificate. I was able to create a CSR with CX509CertificateRequestCertificate and CX509Enrollment classes using the available public key. When I try to read the contents the of CSR in openssl (i used this command: openssl req -in client.csr -noout -text) i get "unable to load X509 request". Is this happening because the CSR does not contain the signature of private key or the CSR is faulty. Kindly help me. Regards, Bharathi -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From kaishen.yy at alipay.com Thu Sep 12 07:50:49 2019 From: kaishen.yy at alipay.com (Paul Yang) Date: Thu, 12 Sep 2019 15:50:49 +0800 Subject: CSR with only public key In-Reply-To: <1568274623649-0.post@n7.nabble.com> References: <1568274623649-0.post@n7.nabble.com> Message-ID: How could you create the CSR with only public key? > On Sep 12, 2019, at 3:50 PM, Bharathi Prasad wrote: > > Hi, > I have the public key of the client but not the private key. I am required > to generate a CSR with only public key. I understand private key is required > for Proof of Possession. However, as per my requirement I am supposed to > create CSR only with public key and my CA would create a certificate. > > I was able to create a CSR with CX509CertificateRequestCertificate and > CX509Enrollment classes using the available public key. When I try to read > the contents the of CSR in openssl (i used this command: openssl req -in > client.csr -noout -text) i get "unable to load X509 request". > > Is this happening because the CSR does not contain the signature of private > key or the CSR is faulty. > > Kindly help me. > > Regards, > Bharathi > > > > -- > Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html Regards, Paul Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From barati.j.prasad at gmail.com Thu Sep 12 08:04:06 2019 From: barati.j.prasad at gmail.com (Bharathi Prasad) Date: Thu, 12 Sep 2019 01:04:06 -0700 (MST) Subject: CSR with only public key In-Reply-To: References: <1568274623649-0.post@n7.nabble.com> Message-ID: <1568275446697-0.post@n7.nabble.com> I used CX509CertificateRequestCertificate class to create CSR with only public key. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From martin.zahn at akadia.com Thu Sep 12 07:58:46 2019 From: martin.zahn at akadia.com (zahn) Date: Thu, 12 Sep 2019 09:58:46 +0200 Subject: Test failed with openssl-1.1.1d ../test/recipes/20-test_enc.t Message-ID: Hello After building openssl-1.1.1d I run a Test and it failed: ../test/recipes/20-test_enc.t ...................... Dubious, test returned 1 (wstat 256, 0x100) Test Summary Report ------------------- ../test/recipes/20-test_enc.t??????????????????? (Wstat: 256 Tests: 172 Failed: 1) ? Failed test:? 171 ? Non-zero exit status: 1 Files=155, Tests=1457, 428 wallclock secs ( 8.43 usr? 0.39 sys + 375.17 cusr 48.13 csys = 432.12 CPU) Result: FAIL make[1]: *** [_tests] Error 1 make[1]: Leaving directory `/u01/download/tmp/openssl-1.1.1d' make: *** [tests] Error 2 I think this is a problem with the 20-test_enc.t Test and not with OPENSSL. Can you please help me to fix the Test ? -- Sch?ne Gr?sse aus Oberdiessbach Martin Zahn Akadia AG Martin Zahn Software Ing. HTL Oracle Certificate Professional Information Technology Fichtenweg 10 CH-3672 Oberdiessbach Tel: +41 79 410 27 87 Web: www.akadia.com E-Mail: martin.zahn at akadia.com From matt at openssl.org Thu Sep 12 08:10:12 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 12 Sep 2019 09:10:12 +0100 Subject: Test failed with openssl-1.1.1d ../test/recipes/20-test_enc.t In-Reply-To: References: Message-ID: On 12/09/2019 08:58, zahn wrote: > Hello > > After building openssl-1.1.1d I run a Test and it failed: > > ../test/recipes/20-test_enc.t ...................... Dubious, test returned 1 > (wstat 256, 0x100) > > Test Summary Report > ------------------- > ../test/recipes/20-test_enc.t??????????????????? (Wstat: 256 Tests: 172 Failed: 1) > ? Failed test:? 171 > ? Non-zero exit status: 1 > Files=155, Tests=1457, 428 wallclock secs ( 8.43 usr? 0.39 sys + 375.17 cusr > 48.13 csys = 432.12 CPU) > Result: FAIL > make[1]: *** [_tests] Error 1 > make[1]: Leaving directory `/u01/download/tmp/openssl-1.1.1d' > make: *** [tests] Error 2 > > I think this is a problem with the 20-test_enc.t Test and not with OPENSSL. > > Can you please help me to fix the Test ? > Did you enable zlib by any chance? If so it could be this: https://github.com/openssl/openssl/issues/9866 No resolution as yet. Matt From Matthias.St.Pierre at ncp-e.com Thu Sep 12 08:31:51 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Thu, 12 Sep 2019 08:31:51 +0000 Subject: AW: Test failed with openssl-1.1.1d ../test/recipes/20-test_enc.t In-Reply-To: References: Message-ID: <21ba14c1c01244cd95b0e0aa1565487b@Ex13.ncp.local> > > I think this is a problem with the 20-test_enc.t Test and not with OPENSSL. > > > > Can you please help me to fix the Test ? > > > > Did you enable zlib by any chance? If so it could be this: > > https://github.com/openssl/openssl/issues/9866 > > No resolution as yet. > > Matt If you need a quick workaround, you have two options: - Don't use the 'zlib' option when configuring OpenSSL - Revert the offending commit 8be96f2369. It is dispensible, because it only fixes a 'cosmetical' problem, namely that in certain situations you have to press CTRL-D in the console more often than expected in order to indicate EOF to the openssl application. https://github.com/openssl/openssl/commit/8be96f236969caabf303bec389a2f812b4869c1c HTH, Matthias From francesco.petruzzi at innovery.net Thu Sep 12 08:41:24 2019 From: francesco.petruzzi at innovery.net (Francesco Petruzzi) Date: Thu, 12 Sep 2019 08:41:24 +0000 Subject: R: CSR with only public key In-Reply-To: References: <1568274623649-0.post@n7.nabble.com> Message-ID: Sign request with a fake private key and hope the client do not require signature verification. Regards Francesco Petruzzi Da: openssl-users [mailto:openssl-users-bounces at openssl.org] Per conto di Paul Yang via openssl-users Inviato: gioved? 12 settembre 2019 09:51 A: Bharathi Prasad Cc: Openssl Users Oggetto: Re: CSR with only public key How could you create the CSR with only public key? On Sep 12, 2019, at 3:50 PM, Bharathi Prasad > wrote: Hi, I have the public key of the client but not the private key. I am required to generate a CSR with only public key. I understand private key is required for Proof of Possession. However, as per my requirement I am supposed to create CSR only with public key and my CA would create a certificate. I was able to create a CSR with CX509CertificateRequestCertificate and CX509Enrollment classes using the available public key. When I try to read the contents the of CSR in openssl (i used this command: openssl req -in client.csr -noout -text) i get "unable to load X509 request". Is this happening because the CSR does not contain the signature of private key or the CSR is faulty. Kindly help me. Regards, Bharathi -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html Regards, Paul Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaishen.yy at alipay.com Thu Sep 12 08:46:09 2019 From: kaishen.yy at alipay.com (Paul Yang) Date: Thu, 12 Sep 2019 16:46:09 +0800 Subject: CSR with only public key In-Reply-To: References: <1568274623649-0.post@n7.nabble.com> Message-ID: <5B514D05-0728-41C4-A607-D24A9B39C7BB@alipay.com> Dare any CA proceed to sign a CSR without verifying the signature? Maybe there are scenarios we are not aware about... > On Sep 12, 2019, at 4:41 PM, Francesco Petruzzi wrote: > > Sign request with a fake private key and hope the client do not require signature verification. > > Regards > Francesco Petruzzi > > Da: openssl-users [mailto:openssl-users-bounces at openssl.org ] Per conto di Paul Yang via openssl-users > Inviato: gioved? 12 settembre 2019 09:51 > A: Bharathi Prasad > Cc: Openssl Users > Oggetto: Re: CSR with only public key > > How could you create the CSR with only public key? > > > On Sep 12, 2019, at 3:50 PM, Bharathi Prasad > wrote: > > Hi, > I have the public key of the client but not the private key. I am required > to generate a CSR with only public key. I understand private key is required > for Proof of Possession. However, as per my requirement I am supposed to > create CSR only with public key and my CA would create a certificate. > > I was able to create a CSR with CX509CertificateRequestCertificate and > CX509Enrollment classes using the available public key. When I try to read > the contents the of CSR in openssl (i used this command: openssl req -in > client.csr -noout -text) i get "unable to load X509 request". > > Is this happening because the CSR does not contain the signature of private > key or the CSR is faulty. > > Kindly help me. > > Regards, > Bharathi > > > > -- > Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html > > > Regards, > > Paul Yang Regards, Paul Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From francesco.petruzzi at innovery.net Thu Sep 12 09:00:36 2019 From: francesco.petruzzi at innovery.net (Francesco Petruzzi) Date: Thu, 12 Sep 2019 09:00:36 +0000 Subject: R: CSR with only public key In-Reply-To: <5B514D05-0728-41C4-A607-D24A9B39C7BB@alipay.com> References: <1568274623649-0.post@n7.nabble.com> <5B514D05-0728-41C4-A607-D24A9B39C7BB@alipay.com> Message-ID: Yes Paul, you are right. Real CA must never accept CSR without verifying the signature. Francesco Petruzzi Information Security Manager Innovery SpA Via Farini, 81 ? 20159 Milano Cell. +39 320 170 4978 Da: Paul Yang [mailto:kaishen.yy at alipay.com] Inviato: gioved? 12 settembre 2019 10:46 A: Francesco Petruzzi Cc: openssl-users at openssl.org Oggetto: Re: CSR with only public key Dare any CA proceed to sign a CSR without verifying the signature? Maybe there are scenarios we are not aware about... On Sep 12, 2019, at 4:41 PM, Francesco Petruzzi > wrote: Sign request with a fake private key and hope the client do not require signature verification. Regards Francesco Petruzzi Da: openssl-users [mailto:openssl-users-bounces at openssl.org] Per conto di Paul Yang via openssl-users Inviato: gioved? 12 settembre 2019 09:51 A: Bharathi Prasad Cc: Openssl Users Oggetto: Re: CSR with only public key How could you create the CSR with only public key? On Sep 12, 2019, at 3:50 PM, Bharathi Prasad > wrote: Hi, I have the public key of the client but not the private key. I am required to generate a CSR with only public key. I understand private key is required for Proof of Possession. However, as per my requirement I am supposed to create CSR only with public key and my CA would create a certificate. I was able to create a CSR with CX509CertificateRequestCertificate and CX509Enrollment classes using the available public key. When I try to read the contents the of CSR in openssl (i used this command: openssl req -in client.csr -noout -text) i get "unable to load X509 request". Is this happening because the CSR does not contain the signature of private key or the CSR is faulty. Kindly help me. Regards, Bharathi -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html Regards, Paul Yang Regards, Paul Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: From fm at 4js.com Thu Sep 12 09:29:53 2019 From: fm at 4js.com (Fabrice Manfroi) Date: Thu, 12 Sep 2019 11:29:53 +0200 Subject: Openssl 1.0.2t build failed using Visual Studio Message-ID: Hello, Trying to build the last 1.0.2t on Windows with Visual Studio 2010, I get the following build error: === LIBEAY32.def : error LNK2001: unresolved external symbol OPENSSL_rdtsc === If I remove the OPENSSL_rdtsc entry from the util/libeay.num file it works without any probleme. Is it a error? Or do I miss something? Best Regards. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From levitte at openssl.org Thu Sep 12 09:53:04 2019 From: levitte at openssl.org (Richard Levitte) Date: Thu, 12 Sep 2019 11:53:04 +0200 Subject: AW: Test failed with openssl-1.1.1d ../test/recipes/20-test_enc.t In-Reply-To: <21ba14c1c01244cd95b0e0aa1565487b@Ex13.ncp.local> References: <21ba14c1c01244cd95b0e0aa1565487b@Ex13.ncp.local> Message-ID: <87v9tx96yn.wl-levitte@openssl.org> On Thu, 12 Sep 2019 10:31:51 +0200, Dr. Matthias St. Pierre wrote: > > > > I think this is a problem with the 20-test_enc.t Test and not with OPENSSL. > > > > > > Can you please help me to fix the Test ? > > > > > > > Did you enable zlib by any chance? If so it could be this: > > > > https://github.com/openssl/openssl/issues/9866 > > > > No resolution as yet. > > > > Matt > > > If you need a quick workaround, you have two options: > > - Don't use the 'zlib' option when configuring OpenSSL > > - Revert the offending commit 8be96f2369. It is dispensible, because it only fixes > a 'cosmetical' problem, namely that in certain situations you have to press > CTRL-D in the console more often than expected in order to indicate EOF to the > openssl application. > > https://github.com/openssl/openssl/commit/8be96f236969caabf303bec389a2f812b4869c1c Reverting the "offending commit" is a bad idea, because the code it corrected was obviously hiding bugs, which would hit others who treat BIO filters correctly (i.e. actually check if there's any pending input or output). Simply put, the zlib BIO filter doesn't behave correctly in this regard. Corrective PR here: https://github.com/openssl/openssl/pull/9876 Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From osmanzakir90 at hotmail.com Thu Sep 12 10:47:03 2019 From: osmanzakir90 at hotmail.com (Osman Zakir) Date: Thu, 12 Sep 2019 10:47:03 +0000 Subject: Building OpenSSL Message-ID: I want to build OpenSSL for an x64 Windows 10 OS. I tried to configure it on the Developer Command Prompt for VS 2019 by running "perl Configure VC-WIN64A", but it gave me this error: " Can't locate Win32/Console.pm in @INC (you may need to install the Win32::Console module) (@INC contains: C:/openssl-1.1.1d/util/perl C:/Perl64/site/lib C:/Perl64/lib) at C:/Perl64/site/lib/ActivePerl/Config.pm line 400. Compilation failed in require at C:/Perl64/site/lib/ExtUtils/MakeMaker.pm line 9.? BEGIN failed--compilation aborted at C:/Perl64/site/lib/ExtUtils/MakeMaker.pm line 9.? Compilation failed in require at C:/Perl64/site/lib/IPC/Cmd.pm line 235. " 2 questions: 1. How can I get Win32/Console.pm and Win32::Console? 2. What does the "A" mean in "Win64A", and what happens if I put "Win64I" instead? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aerowolf at gmail.com Thu Sep 12 13:25:24 2019 From: aerowolf at gmail.com (Kyle Hamilton) Date: Thu, 12 Sep 2019 08:25:24 -0500 Subject: CSR with only public key In-Reply-To: <1568274623649-0.post@n7.nabble.com> References: <1568274623649-0.post@n7.nabble.com> Message-ID: If a CA signs a certificate without proof of possession of the private key, the CA is enabling whoever does have that private key to look as though they are the one who they sign the certificate for (i.e., impersonation). The entire structure of PKI (the binding of the public half of a keypair to some external identity) depends on this not happening. More importantly, in the situation where the person submitting the unsigned request can't prove possession, they know it is a situation where either the private key is lost (and the certificate would be useless anyway) or that impersonation is simply guaranteed. There might be a scenario desired where the generation of the CSR isn't done by the holder of the private key internal to a company (perhaps because the holder of the private key is otherwise extremely busy), but because there's no way to tell if that limited scenario is different from the other scenarios based on available evidence, publicly trusted CAs are required (by rules of the CABF) to reject non-proof-of-possession scenarios entirely. To answer your question, yes the error is because the request wasn't signed with the private key. As such, it's not a complete request, and doesn't match the expected ASN.1 structure. -Kyle H On Thu, Sep 12, 2019, 02:47 Bharathi Prasad wrote: > Hi, > I have the public key of the client but not the private key. I am required > to generate a CSR with only public key. I understand private key is > required > for Proof of Possession. However, as per my requirement I am supposed to > create CSR only with public key and my CA would create a certificate. > > I was able to create a CSR with CX509CertificateRequestCertificate and > CX509Enrollment classes using the available public key. When I try to read > the contents the of CSR in openssl (i used this command: openssl req -in > client.csr -noout -text) i get "unable to load X509 request". > > Is this happening because the CSR does not contain the signature of private > key or the CSR is faulty. > > Kindly help me. > > Regards, > Bharathi > > > > -- > Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Sep 12 14:29:54 2019 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 12 Sep 2019 14:29:54 +0000 Subject: CSR with only public key In-Reply-To: <1568275446697-0.post@n7.nabble.com> References: <1568274623649-0.post@n7.nabble.com> <1568275446697-0.post@n7.nabble.com> Message-ID: <11B8F391-EF28-49EB-B517-B50E02A6ABB2@akamai.com> > I used CX509CertificateRequestCertificate class to create CSR with only public key. Those functions/classes/names/whatever are not part of OpenSSL. The OpenSSL "req" command cannot process as CSR unless it is signed by the private key. If you have a requirement to sign a CSR with the public key, then probably other things within OpenSSL will not be able to handle it. From openssl-users at dukhovni.org Thu Sep 12 14:56:54 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 12 Sep 2019 10:56:54 -0400 Subject: CSR with only public key In-Reply-To: <1568274623649-0.post@n7.nabble.com> References: <1568274623649-0.post@n7.nabble.com> Message-ID: <20190912145654.GJ21772@straasha.imrryr.org> On Thu, Sep 12, 2019 at 12:50:23AM -0700, Bharathi Prasad wrote: > I have the public key of the client but not the private key. I am required > to generate a CSR with only public key. I understand private key is required > for Proof of Possession. However, as per my requirement I am supposed to > create CSR only with public key and my CA would create a certificate. > > I was able to create a CSR with CX509CertificateRequestCertificate and > CX509Enrollment classes using the available public key. When I try to read > the contents the of CSR in openssl (i used this command: openssl req -in > client.csr -noout -text) i get "unable to load X509 request". > > Is this happening because the CSR does not contain the signature of private > key or the CSR is faulty. The input is not a valid PEM-encoded CSR. Perhaps it is DER encoded. To test: openssl req -inform DER -in client.csr -text -- Viktor. From fm at 4js.com Thu Sep 12 15:35:08 2019 From: fm at 4js.com (Fabrice Manfroi) Date: Thu, 12 Sep 2019 17:35:08 +0200 Subject: Typo in crypto/threads_none.c source file Message-ID: <94d6d961-6c36-bf01-c4b4-af68f46f5ec3@4js.com> Hello, During a Windows build of the 1.1.1d version I found a typo in the crypto/threads_none.c source file. In attachment a small patch which fix the problem. Best Regards. -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-1.1.1d.patch Type: text/x-diff Size: 394 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From matt at openssl.org Thu Sep 12 15:39:43 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 12 Sep 2019 16:39:43 +0100 Subject: Typo in crypto/threads_none.c source file In-Reply-To: <94d6d961-6c36-bf01-c4b4-af68f46f5ec3@4js.com> References: <94d6d961-6c36-bf01-c4b4-af68f46f5ec3@4js.com> Message-ID: On 12/09/2019 16:35, Fabrice Manfroi wrote: > Hello, > > During a Windows build of the 1.1.1d version I found a typo in the > crypto/threads_none.c source file. Hi This was recently fixed in git. See commit c3656cc594daa. Matt From matt at openssl.org Thu Sep 12 16:28:35 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 12 Sep 2019 17:28:35 +0100 Subject: Openssl 1.0.2t build failed using Visual Studio In-Reply-To: References: Message-ID: On 12/09/2019 10:29, Fabrice Manfroi wrote: > Hello, > > Trying to build the last 1.0.2t on Windows with Visual Studio 2010, I > get the following build error: > > === > > LIBEAY32.def : error LNK2001: unresolved external symbol OPENSSL_rdtsc > > === > > If I remove the OPENSSL_rdtsc entry from the util/libeay.num file it > works without any probleme. > > Is it a error? Or do I miss something? I don't get this with VS2013 (the oldest version I have) so it may be a Visual Studio version specific problem. OPENSSL_rdtsc is only relevant on some platforms, and isn't present on others which is why this problem occurs. Perhaps later Visual Studio versions are more tolerant of this? Removing the entry from util/libeay.num is fine as a workaround for now, and won't cause any adverse impacts. Matt From osmanzakir90 at hotmail.com Thu Sep 12 16:39:32 2019 From: osmanzakir90 at hotmail.com (Osman Zakir) Date: Thu, 12 Sep 2019 16:39:32 +0000 Subject: Building OpenSSL In-Reply-To: References: Message-ID: Okay, I was able to build it and am running the tests now. How do I know whether to enable RC5 or MD4, though? Which one do I enable? Sorry if this is a stupid question. And what's "afalg" (in "test_afalf")? -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmanzakir90 at hotmail.com Thu Sep 12 17:45:27 2019 From: osmanzakir90 at hotmail.com (Osman Zakir) Date: Thu, 12 Sep 2019 17:45:27 +0000 Subject: Building OpenSSL In-Reply-To: References: , Message-ID: I tried enabling both MD2 and RC5 but I got linker errors when trying to build: " Creating library apps\openssl.lib and object apps\openssl.exp speed.obj : error LNK2019: unresolved external symbol EVP_md2 referenced in function EVP_Digest_MD2_loop? speed.obj : error LNK2019: unresolved external symbol MD2_options referenced in function speed_main? version.obj : error LNK2001: unresolved external symbol MD2_options? speed.obj : error LNK2019: unresolved external symbol RC5_32_set_key referenced in function speed_main? speed.obj : error LNK2019: unresolved external symbol RC5_32_cbc_encrypt referenced in function speed_main? apps\openssl.exe : fatal error LNK1120: 4 unresolved externals? NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.22.27905\bin\HostX64\x64\link.EXE"' : return code '0x460'? Stop.? NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.22.27905\bin\HostX64\x64\nmake.exe"' : return code '0x2'? Stop. " Any help would be appreciated. Thanks in advance. ________________________________ From: openssl-users on behalf of Osman Zakir Sent: Thursday, September 12, 2019 9:39 PM To: openssl-users at openssl.org Subject: Re: Building OpenSSL Okay, I was able to build it and am running the tests now. How do I know whether to enable RC5 or MD4, though? Which one do I enable? Sorry if this is a stupid question. And what's "afalg" (in "test_afalf")? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Thu Sep 12 19:33:28 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 12 Sep 2019 19:33:28 +0000 Subject: Building OpenSSL In-Reply-To: References: , Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Osman Zakir > Sent: Thursday, September 12, 2019 13:45 > I tried enabling both MD2 and RC5 Your previous note said "RC5 or MD4". Are you talking about MD2 or MD4? > but I got linker errors when trying to build: How did you "enable" them? If you reconfigured, did you do a "make clean" afterward before trying to build? > How do I know whether to enable RC5 or MD4, though? That depends on the needs of your application(s). > Which one do I enable? Sorry if this is a stupid question. Neither. Either. Both. (All, since there seems to be some MD2/MD4 confusion here.) It depends entirely on what you're building OpenSSL for. You haven't told us, so we have no way of answering your question. Most people have no need for MD2, MD4, or RC5. > And what's "afalg" (in "test_afalf")? AF_ALG is a Linux network address family for userland access to the kernel cryptography subystem. OpenSSL's afalg is (I believe) an engine (i.e. an OpenSSL plugin) that lets OpenSSL use AF_ALG for some cryptographic operations. It's similar in purpose to several of the other engines, such as capi (interface to Windows Crypto API) and pkcs11 (interface to crypto hardware supporting the PKCS#11 standard). If that doesn't answer your question, then you probably don't need to know about it. -- Michael Wojcik Distinguished Engineer, Micro Focus From bix191 at gmail.com Thu Sep 12 20:52:08 2019 From: bix191 at gmail.com (Bin Ichiki) Date: Fri, 13 Sep 2019 05:52:08 +0900 Subject: Openssl 1.0.2t build failed using Visual Studio In-Reply-To: References: Message-ID: The same build error is occurred by visual studio 2017 community edition. Specified Configure options is VC-WIN64A and no-asm. -------------- next part -------------- An HTML attachment was scrubbed... URL: From barati.j.prasad at gmail.com Fri Sep 13 03:56:58 2019 From: barati.j.prasad at gmail.com (Bharathi Prasad) Date: Thu, 12 Sep 2019 20:56:58 -0700 (MST) Subject: CSR with only public key In-Reply-To: <20190912145654.GJ21772@straasha.imrryr.org> References: <1568274623649-0.post@n7.nabble.com> <20190912145654.GJ21772@straasha.imrryr.org> Message-ID: <1568347018348-0.post@n7.nabble.com> Hi, Thanks for the prompt replies. I agree signature from private key should be present in a CSR. However, as per RFC 2511, Proof Of Possession is optional though it strongly recommends to have it. I was able to create the CSR with only public key. I was unintentionally adding an extra line at the end while writing to a file. That is the reason for the error. However, i have rectified it and now i am able to view the CSR contents with openssl req command. I am yet to check if I can get a valid certificate from my CA. But thanks for the help. Regards, Bharathi -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From walter.h at mathemainzel.info Fri Sep 13 03:50:43 2019 From: walter.h at mathemainzel.info (Walter H.) Date: Fri, 13 Sep 2019 05:50:43 +0200 Subject: CSR with only public key In-Reply-To: <1568274623649-0.post@n7.nabble.com> References: <1568274623649-0.post@n7.nabble.com> Message-ID: Hey, Try calculating the private Key from the public key ;-) but this can last a little time you don't have; Walter On Thu, September 12, 2019 09:50, Bharathi Prasad wrote: > Hi, > I have the public key of the client but not the private key. > ... > > Regards, > Bharathi From barati.j.prasad at gmail.com Fri Sep 13 04:23:50 2019 From: barati.j.prasad at gmail.com (Bharathi Prasad) Date: Thu, 12 Sep 2019 21:23:50 -0700 (MST) Subject: CSR with only public key In-Reply-To: References: <1568274623649-0.post@n7.nabble.com> Message-ID: <1568348630323-0.post@n7.nabble.com> You are right. Cannot create a certificate with CSR containing only public key. Thanks for the explanation. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From gerhard.jahn at atos.net Fri Sep 13 05:20:22 2019 From: gerhard.jahn at atos.net (Jahn, Gerhard) Date: Fri, 13 Sep 2019 05:20:22 +0000 Subject: SSL_get_error() crash (shortened) Message-ID: <16996762554f47ea87257db45d07446b@atos.net> Hello, We're using OpenSSl 1.1.1b on WIN64 and are facing a (rare but strange) core-dump when doing the following: After successful TLS1.3 handshake we're calling SSL_read() to get the first 2 Bytes of PDU data from the new connection (ASN.1 TAG + length). SSL_read() returns 0 According to OpenSSL 1.1.1 documentation: For SSL_read() and SSL_peek() the following return values can occur: <= 0 The read operation was not successful, because either the connection was closed, an error occurred or action must be taken by the calling process. Call SSL_get_error(3) with the return value ret to find out the reason. We follow and call SSL_get_error() which crashes with debugger output (only topmost frame is shown here) LIBSSL!SSL_get_error(struct ssl_st * s = 0x00000000`05be9a00, int i = )+0x18c [d:\data\openssl\64\openssl-1.1.1b\ssl\ssl_lib.c @ 3560] The OpenSSL source at this reported line looks like: if ((s->shutdown & SSL_RECEIVED_SHUTDOWN) && (s->s3->warn_alert == SSL_AD_CLOSE_NOTIFY)) return SSL_ERROR_ZERO_RETURN; when we inspect the session "s" in the debugger, we find that s->shutdown == 3 and s->s3 == NULL which finally causes the crash It looks like a bug in OpenSSL....??? So far it happened only once in our LAB (after some hours of heavy SSL load testing with thousands of SSL connections created/deleted....) we're currently not able to reproduce it..... Any comments/ideas/fixes would be appreciated...... Gerhard Jahn Senior Developer IAM - AITs GER BDS CySP DIRX PDM T +49 (0) 211 399 33276 T +49 (0) 211 399 22891 gerhard.jahn at atos.net Atos Information Technology GmbH Otto-Hahn-Ring 6 81739 Munich, Germany atos.net/de << OLE Object: Picture (Device Independent Bitmap) >> Atos Information Technology GmbH Managing Directors: Ursula Morgenstern, Udo Littke; Chairman of the Supervisory Board: Eric Grall; Registered office: Munich; Commercial register of the local court of Munich, HRB 235509 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mann.patidar at gmail.com Fri Sep 13 14:37:23 2019 From: mann.patidar at gmail.com (Manish Patidar) Date: Fri, 13 Sep 2019 20:07:23 +0530 Subject: Truncated Hmac and supported group extension in openssl1.1.1 Message-ID: Hi Is truncated hmac extension is supported in openssl1.1.1 ? is TLS1. 2 and lower TLS version supports supported group extension for Finite Field GROUPS (DHE) ? Regards Manish -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmanzakir90 at hotmail.com Fri Sep 13 15:30:08 2019 From: osmanzakir90 at hotmail.com (Osman Zakir) Date: Fri, 13 Sep 2019 15:30:08 +0000 Subject: Linker errors when trying to build OpenSSL with MD2 and RC5 support Message-ID: I had linker errors when trying to build OpenSSL with MD2 and RC5 support. I ran this command: " perl Configure VC-WIN64A --with-zlib-lib=C:/zlib/lib/zlibstatic --with-zlib-include=C:/zlib/include enable-md2 enable-rc5 --release " and had the messages I've put in this Gist in the output: https://gist.github.com/DragonOsman/e81ff5590561d999dce5b2f7ddb9d3bd . I had some warnings and one error from the Linker when trying to build the Win32::Console Perl module, but I still got the module itself. Could that be a reason for my problem? And also, how can I enable all of the cryptography algorithms without getting errors (is this possible?)? I'm also tempted to try getting the latest bleeding edge version from GitHub. I wonder if I should try that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgh at wizmail.org Fri Sep 13 15:56:43 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Fri, 13 Sep 2019 16:56:43 +0100 Subject: SSL_get_certificate In-Reply-To: <526EEF97-EEF7-4E7D-BF14-81A6147EFCE1@dukhovni.org> References: <50968caa-f7a5-5632-d074-a2d66f66f914@wizmail.org> <3d8625de-319a-827e-968d-b89fd40c02d3@wizmail.org> <526EEF97-EEF7-4E7D-BF14-81A6147EFCE1@dukhovni.org> Message-ID: <4983e0ba-e6f6-d6e0-41d4-5c00baded1f6@wizmail.org> On 09/09/2019 16:21, Viktor Dukhovni wrote: > One of the "CHANGES" entries for 1.0.1d reads: > > *) Call OCSP Stapling callback after ciphersuite has been chosen, so > the right response is stapled. Also change SSL_get_certificate() > so it returns the certificate actually sent. > See http://rt.openssl.org/Ticket/Display.html?id=2836. > [Rob Stradling ] > > Consequently 1.0.1d and later had the expected behaviour. However, > in commits this was updated: > > dc144417571735c82853421a8845ef603d828a0b (1.0.2-beta1) > e5db9c3b67deb80e274f66e3832a9cfba931670c (also master, at the time 1.1.0-dev) > > Minor enhancement to PR#2836 fix. Instead of modifying SSL_get_certificate > change the current certificate (in s->cert->key) to the one used and then > SSL_get_certificate and SSL_get_privatekey will automatically work. > > The code for "change the current certificate" was: > But it only runs if there's a "tlsext_status_cb" callback, which may > not cover all the expected use-cases. I think this merits a new > issue on Github. Thanks. Fortunately it covers mine; I "just" need to work out how to match up an OCSP resp to the cert. Could we also get SSL_get_certificate documented? It doesn't seem to be currently, despite https://www.openssl.org/docs/manmaster/man3/SSL_get_tlsext_status_ocsp_resp.html saying the server should use it. Another reason for wanting this will be for TLS1.3 with whole-chain stapling. I wonder whether the library could provide more built-in support for stapling - attaching the status (chain)(s) to the server certificate chain(s) before SSL_accept() rather than doing (multiple) callbacks on seeing the client status-request. -- Cheers, Jeremy From Michael.Wojcik at microfocus.com Fri Sep 13 15:52:53 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 13 Sep 2019 15:52:53 +0000 Subject: Linker errors when trying to build OpenSSL with MD2 and RC5 support In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Osman Zakir > Sent: Friday, September 13, 2019 11:30 > I had linker errors when trying to build OpenSSL with MD2 and RC5 support. Did you clean after configuring? > I'm also tempted to try getting the latest bleeding edge version from GitHub. I > wonder if I should try that. If you're bored with your current set of problems and want a different set, sure. If you're hoping to make progress, I wouldn't recommend it. -- Michael Wojcik Distinguished Engineer, Micro Focus From narasimha.nayak at gmail.com Fri Sep 13 16:47:52 2019 From: narasimha.nayak at gmail.com (Narasimha Nayak) Date: Fri, 13 Sep 2019 09:47:52 -0700 Subject: OpenSSL: ASYNC operations and application callback function. Message-ID: Hello All, I am investigating the usage of OpenSSL v1.1.1.c with QAT offload. As part of the investigation to enable ASYNC mode for SSL ops I came across the possibility of providing callbacks via ?SSL_CTX_set_async_callback?, and not use poll/select as required earlier. The callback functionality has been added via commit ( https://github.com/openssl/openssl/commit/9f5a87fd665cb597fa1c1f4eef882d2d2f833e61) in Nov, 2018. These changes are not yet part of OpenSSL v1.1.1c/d. Hence I would like to understand the following: 1. Is this feature complete and use-able with QAT engine provided by Intel for OpenSSL ? Are there any drawbacks to be aware of ? 2. Do we have any examples to depict the usage for these APIs ? Will help to know if there are any corner cases to handle. Any feedback is much appreciated. -- Thanks and Regards, Narasimha -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmanzakir90 at hotmail.com Fri Sep 13 17:26:28 2019 From: osmanzakir90 at hotmail.com (Osman Zakir) Date: Fri, 13 Sep 2019 17:26:28 +0000 Subject: Linker errors when trying to build OpenSSL with MD2 and RC5 support In-Reply-To: References: , Message-ID: I had a successful build before I configured it again to try to get MD2 and RC5, so I didn't see a reason to clean the build. I did clean it now after the failure happened. I'll try to fix these errors for now, so please help me with that. But I also want to know after that whether or not it's possible to enable all of the algorithms supported by OpenSSL version 1.1.1d. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Carl.Tietjen at microfocus.com Fri Sep 13 18:17:34 2019 From: Carl.Tietjen at microfocus.com (Carl Tietjen) Date: Fri, 13 Sep 2019 18:17:34 +0000 Subject: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc In-Reply-To: <87zhja8kqp.wl-levitte@openssl.org> References: <7a0ad1fd-093c-56bb-8764-f824eb74c499@openssl.org> <871rwma4uz.wl-levitte@openssl.org> <87zhja8kqp.wl-levitte@openssl.org> Message-ID: So the https://www.openssl.org/source/openssl-1.0.2t.tar.gz.sha256 file still has the issue. All the other files from the main download page are OK Carl -----Original Message----- From: Richard Levitte [mailto:levitte at openssl.org] Sent: Wednesday, September 11, 2019 4:41 PM To: Carl Tietjen Cc: Richard Levitte ; Michael Wojcik ; Matt Caswell ; openssl-users at openssl.org Subject: Re: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc Thanks for the heads up. For some reason, the information at our CDN remained incorrect for the "BAD" files, so I purged all the current release files there, so their cache for them would rebuild from scratch. They look better now. Cheers, Richard On Thu, 12 Sep 2019 00:25:40 +0200, Carl Tietjen wrote: > > > Still seeing the issue for SOME of the SHA256 files... I waited for a > while thinking it might be a cache issue, but no change. > > https://www.openssl.org/source/openssl-1.0.2t.tar.gz.sha256 -- BAD > > https://www.openssl.org/source/openssl-1.1.0l.tar.gz.sha256 -- OK > > https://www.openssl.org/source/openssl-1.1.1d.tar.gz.sha256 -- BAD > > https://www.openssl.org/source/openssl-fips-2.0.16.tar.gz.sha256 -- OK > > https://www.openssl.org/source/openssl-fips-ecp-2.0.16.tar.gz.sha256 > -- OK > > -----Original Message----- > From: Richard Levitte [mailto:levitte at openssl.org] > Sent: Wednesday, September 11, 2019 2:41 PM > To: Michael Wojcik > Cc: Carl Tietjen ; Matt Caswell > ; openssl-users at openssl.org > Subject: Re: Problem with the SHA256 signatures (download files) for > the new releases 1.1.1d, 1.0.2t, 1.1.0l etc > > Issue found... Apache detected .gz in the file name and set the > encoding to 'application/ x-gzip'... Apparently, we already force > .asc and .sha1 files to application/binary, but have apparently not added a similar directive for .sha256 files. > > Now done. > > Cheers, > > Richard > > On Wed, 11 Sep 2019 22:04:53 +0200, > > Michael Wojcik wrote: > > > > > > I can confirm Carl's issue when I download using Pale Moon (a Firefox fork): > > > > > > ----- > > > $ file openssl-1.1.1d.tar.gz.sha256 > > > openssl-1.1.1d.tar.gz.sha256: gzip compressed data, from FAT > > > filesystem (MS-DOS, OS/2, NT) > > > > > > $ file openssl-1.1.1d.tar.gz.sha1 > > > openssl-1.1.1d.tar.gz.sha1: ASCII text > > > > > > $ file openssl-1.1.1d.tar.gz.asc > > > openssl-1.1.1d.tar.gz.asc: PGP signature Signature (old) > > > > > > $ gpg --verify openssl-1.1.1d.tar.gz.asc openssl-1.1.1d.tar.gz > > > gpg: Signature made 09/10/19 09:13:14 EDT using RSA key ID 0E604491 > > > gpg: Good signature from "Matt Caswell " [full] > > > gpg: aka "Matt Caswell " [full] > > > ----- > > > > > > So the .sha1 file and the signature look fine, but the .sha256 file > > is apparently a fragment of > gzip-compressed data. And ... let's see ... gunzip'ing it gives us the > SHA256 hash in ASCII. So my guess the server is gzip'ing it (or it's > gzip'ed at rest on the server), but the server isn't setting the > content-transfer-encoding correctly. Chrome might be content-sniffing and decompressing based on that. I haven't looked at the response headers though. > > > > > > (Personally, I always check the signature and don't bother with the > > > posted hashes.) > > > > > > -- > > > Michael Wojcik > > > Distinguished Engineer, Micro Focus > > > > > > > > -- > > Richard Levitte levitte at openssl.org > > OpenSSL Project http://www.openssl.org/~levitte/ > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From Michael.Wojcik at microfocus.com Fri Sep 13 18:41:22 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 13 Sep 2019 18:41:22 +0000 Subject: Linker errors when trying to build OpenSSL with MD2 and RC5 support In-Reply-To: References: , Message-ID: > From: Osman Zakir [mailto:osmanzakir90 at hotmail.com] > Sent: Friday, September 13, 2019 13:26 > I had a successful build before I configured it again to try to get MD2 and RC5, so I > didn't see a reason to clean the build. Reconfiguring changes the makefiles. You should always clean after a reconfigure. That's true for the vast majority of software projects that use a makefile-creating build process. > But I also want to know after that whether or not it's possible to enable all of the > algorithms supported by OpenSSL version 1.1.1d. If it's not possible to enable an algorithm, it isn't actually "supported", is it? If Configure claims a particular algorithm can be enabled, then if it's not actually possible to build with it enabled and use it, I'd say that's a bug somewhere. I haven't tried to build with all possible Configure options enabled, though. -- Michael Wojcik Distinguished Engineer, Micro Focus From osmanzakir90 at hotmail.com Fri Sep 13 20:46:39 2019 From: osmanzakir90 at hotmail.com (Osman Zakir) Date: Fri, 13 Sep 2019 20:46:39 +0000 Subject: MD2 or RC5? Message-ID: I'd still like to know if it's possible to enable to both. If it's not, though, then which one is best to enable? MD2 or RC5? Thanks in advantage for the reply and sorry for the new email thread. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Sep 13 20:50:52 2019 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 13 Sep 2019 20:50:52 +0000 Subject: MD2 or RC5? In-Reply-To: References: Message-ID: <5E5AB186-BA6A-4EE7-BFC8-A2327423D3F5@akamai.com> * I'd still like to know if it's possible to enable to both. If it's not, though, then which one is best to enable? MD2 or RC5? Thanks in advantage for the reply and sorry for the new email thread. They do different things; MD2 is a digest (?hash?) function, and RC5 is a block (encrypt/decrypt) cipher. Both are obsolete. You should be able to enable both, but you should only do so if you need to work with some really old software. -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmanzakir90 at hotmail.com Fri Sep 13 22:05:36 2019 From: osmanzakir90 at hotmail.com (Osman Zakir) Date: Fri, 13 Sep 2019 22:05:36 +0000 Subject: Linker errors when trying to build OpenSSL with MD2 and RC5 support In-Reply-To: References: , , , Message-ID: I'll just put both email addresses in for "To" then. I won't build with either one enabled if that's better, but I'd still like to know how to fix those linker errors. I do also want to ask what AFALG is and if I should enable it or not (and what happens if I do). -------------- next part -------------- An HTML attachment was scrubbed... URL: From malz at jetlan.com Sat Sep 14 04:03:46 2019 From: malz at jetlan.com (Mal) Date: Sat, 14 Sep 2019 13:33:46 +0930 Subject: 1.1.1d LD_LIBRARY_PATH Message-ID: Hi, On restart on my host with version 1.1.1d , I have this problem: > HOST:/ # openssl version openssl: /usr/lib/arm-linux-gnueabihf/libssl.so.1.1: version `OPENSSL_1_1_1' not found (required by openssl) openssl: /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1: version `OPENSSL_1_1_1' not found (required by openssl) When i manually add LD_LIBRARY_PATH, we get back in business: > HOST:/ # export LD_LIBRARY_PATH=/os/openssl-1.1.1d HOST:/ # openssl version OpenSSL 1.1.1d 10 Sep 2019 Would someone let me know how to add this path permanently, as currently i need to re-add on restart ? Thanks.. From hmurray at megapathdsl.net Sat Sep 14 05:56:39 2019 From: hmurray at megapathdsl.net (Hal Murray) Date: Fri, 13 Sep 2019 22:56:39 -0700 Subject: 1.1.1d LD_LIBRARY_PATH In-Reply-To: Message from Mal via openssl-users of "Sat, 14 Sep 2019 13:33:46 +0930." Message-ID: <20190914055639.D291D40605C@ip-64-139-1-69.sjc.megapath.net> > Would someone let me know how to add this path permanently, as currently i > need to re-add on restart ? man ld, search for rpath -- These are my opinions. I hate spam. From aerowolf at gmail.com Sat Sep 14 11:35:44 2019 From: aerowolf at gmail.com (Kyle Hamilton) Date: Sat, 14 Sep 2019 06:35:44 -0500 Subject: 1.1.1d LD_LIBRARY_PATH In-Reply-To: References: Message-ID: You might be able to set this in the equivalent of /etc/ld.so.conf and rerun ldconfig(8), but those specific operations rely on the GNU dynamic linker. The only clue that suggests it may be GNU's dynamic linker is the LD_LIBRARY_PATH environment variable name. If it's not, you'll have to look up your platform's dynamic linking process and set it yourself. -Kyle H On Fri, Sep 13, 2019, 23:12 Mal via openssl-users wrote: > Hi, > > On restart on my host with version 1.1.1d , I have this problem: > > > HOST:/ # openssl version > openssl: /usr/lib/arm-linux-gnueabihf/libssl.so.1.1: version > `OPENSSL_1_1_1' not found (required by openssl) > openssl: /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1: version > `OPENSSL_1_1_1' not found (required by openssl) > > > When i manually add LD_LIBRARY_PATH, we get back in business: > > > HOST:/ # export LD_LIBRARY_PATH=/os/openssl-1.1.1d > HOST:/ # openssl version > OpenSSL 1.1.1d 10 Sep 2019 > > > > Would someone let me know how to add this path permanently, as currently > i need to re-add on restart ? > > Thanks.. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sat Sep 14 13:35:19 2019 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 14 Sep 2019 13:35:19 +0000 Subject: 1.1.1d LD_LIBRARY_PATH In-Reply-To: References: Message-ID: <2EA265FF-B505-4A93-9E5A-29D69097AC85@akamai.com> On restart on my host with version 1.1.1d , I have this problem: I hope you are not replacing your system OpenSSL with one you built. Don't do that. From Michael.Wojcik at microfocus.com Sat Sep 14 14:33:38 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Sat, 14 Sep 2019 14:33:38 +0000 Subject: Linker errors when trying to build OpenSSL with MD2 and RC5 support In-Reply-To: References: , , , Message-ID: > From: Osman Zakir [mailto:osmanzakir90 at hotmail.com] > Sent: Friday, September 13, 2019 18:06 > I won't build with either one enabled if that's better, but I'd still like to know how > to fix those linker errors. Someone should probably look into that, but I don't have time to; and if no one else from the community picks it up, you'll probably have to wait until someone from the OpenSSL team has a chance to get to it. Does the DLL you built have the missing symbols? (Try "dumpbin /exports libssl-1_1-x64.dll | findstr EVP_md2" in the apps directory.) If so, the link is picking up the wrong import library. If not, something didn't get rebuilt correctly. > I do also want to ask what AFALG is and if I should enable it or not (and what happens > if I do). I answered this in one of my other replies, sent Thursday 12 September. The afalg engine is only applicable to Linux. -- Michael Wojcik Distinguished Engineer, Micro Focus From Michael.Wojcik at microfocus.com Sat Sep 14 18:18:26 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Sat, 14 Sep 2019 18:18:26 +0000 Subject: Linker errors when trying to build OpenSSL with MD2 and RC5 support In-Reply-To: References: , , , , Message-ID: Again, please don't send questions about OpenSSL directly to me. I am not a member of the OpenSSL Project. > From: Osman Zakir [mailto:osmanzakir90 at hotmail.com] > Sent: Saturday, September 14, 2019 10:54 > I'm not trying to build a DLL, though. I want to build a static .lib library (are there > additional commands I need to give to make it build static libs?). Yes, and they're documented in the Configure options just like everything else. You need to configure with "no-shared" to disable the building of shared libraries. You may want no-dynamic-engine to have engines linked statically rather than loaded at runtime, no-zlib-dynamic for the same reason, and no-dso to disable loading of objects at runtime (though I'm not sure this has any effect on Windows builds). I don't think no-pic has any effect on Windows. I can't guess what options you actually might want because you STILL haven't told us what you're trying to do, and why. -- Michael Wojcik Distinguished Engineer, Micro Focus From osmanzakir90 at hotmail.com Sat Sep 14 20:51:05 2019 From: osmanzakir90 at hotmail.com (Osman Zakir) Date: Sat, 14 Sep 2019 20:51:05 +0000 Subject: Linker errors when trying to build OpenSSL with MD2 and RC5 support In-Reply-To: References: , , , , , Message-ID: Are there additional commands I have to pass to the Configure module if I want to build completely static libs? If so, what are they? -------------- next part -------------- An HTML attachment was scrubbed... URL: From erbsharma021 at gmail.com Sat Sep 14 21:28:35 2019 From: erbsharma021 at gmail.com (Bhuvan Sharma) Date: Sat, 14 Sep 2019 23:28:35 +0200 Subject: Problem in trying EVP Key Derivation example in openssl Message-ID: Hey all, I'm new to openssl community and I don't know much about it. I tried to use openssl on my linux machine. I clone openssl git repo and executed these commands as mentioned in the file "INSTALL": "./config", "make", "make test", "make install". It went alright. Then I tried an "EVP KEY Derivation" example from this link: https://wiki.openssl.org/index.php?title=EVP_Key_Derivation&redirect=no#targetText=HKDF%20was%20designed%20by%20Krawczyk,from%20the%20OpenSSL%20man%20pages. But it gives me some error for undeclared function. ~/openssl$ gcc -std=c99 test.c -o test.exe -l:libcrypto.a -pthread -ldl test.c: In function ?main?: test.c:12:17: warning: implicit declaration of function ?EVP_KDF_CTX_new_id?; did you mean ?EVP_KDF_CTX_new?? [-Wimplicit-function-declaration] if ((kctx = EVP_KDF_CTX_new_id(EVP_KDF_HKDF)) == NULL) { ^~~~~~~~~~~~~~~~~~ EVP_KDF_CTX_new test.c:12:36: error: ?EVP_KDF_HKDF? undeclared (first use in this function); did you mean ?EVP_PKEY_HKDF?? if ((kctx = EVP_KDF_CTX_new_id(EVP_KDF_HKDF)) == NULL) { ^~~~~~~~~~~~ EVP_PKEY_HKDF test.c:12:36: note: each undeclared identifier is reported only once for each function it appears in test.c:13:9: warning: implicit declaration of function ?error?; did you mean ?perror?? [-Wimplicit-function-declaration] error("EVP_KDF_CTX_new_id"); ^~~~~ perror test.c:15:9: warning: implicit declaration of function ?EVP_KDF_ctrl?; did you mean ?EVP_KDF_size?? [-Wimplicit-function-declaration] if (EVP_KDF_ctrl(kctx, EVP_KDF_CTRL_SET_MD, EVP_sha256()) <= 0) { ^~~~~~~~~~~~ EVP_KDF_size Is there any problem with the installation or am I missing something else? Your help is much appreciated. Thanks & Regards, Bhuvan Sharma -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Sat Sep 14 23:16:25 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Sun, 15 Sep 2019 09:16:25 +1000 Subject: Problem in trying EVP Key Derivation example in openssl In-Reply-To: References: Message-ID: <9A5E6F46-667F-4AD8-8B68-9EC6DA8BD707@oracle.com> The example is wrong. The KDF API changed recently to better match the way the rest of the project is moving. I?ll update the example. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 15 Sep 2019, at 7:28 am, Bhuvan Sharma wrote: > > Hey all, > I'm new to openssl community and I don't know much about it. I tried to use openssl on my linux machine. I clone openssl git repo and executed these commands as mentioned in the file "INSTALL": "./config", "make", "make test", "make install". It went alright. Then I tried an "EVP KEY Derivation" example from this link: https://wiki.openssl.org/index.php?title=EVP_Key_Derivation&redirect=no#targetText=HKDF%20was%20designed%20by%20Krawczyk,from%20the%20OpenSSL%20man%20pages . But it gives me some error for undeclared function. > ~/openssl$ gcc -std=c99 test.c -o test.exe -l:libcrypto.a -pthread -ldl > test.c: In function ?main?: > test.c:12:17: warning: implicit declaration of function ?EVP_KDF_CTX_new_id?; did you mean ?EVP_KDF_CTX_new?? [-Wimplicit-function-declaration] > if ((kctx = EVP_KDF_CTX_new_id(EVP_KDF_HKDF)) == NULL) { > ^~~~~~~~~~~~~~~~~~ > EVP_KDF_CTX_new > test.c:12:36: error: ?EVP_KDF_HKDF? undeclared (first use in this function); did you mean ?EVP_PKEY_HKDF?? > if ((kctx = EVP_KDF_CTX_new_id(EVP_KDF_HKDF)) == NULL) { > ^~~~~~~~~~~~ > EVP_PKEY_HKDF > test.c:12:36: note: each undeclared identifier is reported only once for each function it appears in > test.c:13:9: warning: implicit declaration of function ?error?; did you mean ?perror?? [-Wimplicit-function-declaration] > error("EVP_KDF_CTX_new_id"); > ^~~~~ > perror > test.c:15:9: warning: implicit declaration of function ?EVP_KDF_ctrl?; did you mean ?EVP_KDF_size?? [-Wimplicit-function-declaration] > if (EVP_KDF_ctrl(kctx, EVP_KDF_CTRL_SET_MD, EVP_sha256()) <= 0) { > ^~~~~~~~~~~~ > EVP_KDF_size > > Is there any problem with the installation or am I missing something else? > Your help is much appreciated. > > Thanks & Regards, > Bhuvan Sharma -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Sat Sep 14 23:41:03 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Sun, 15 Sep 2019 09:41:03 +1000 Subject: Problem in trying EVP Key Derivation example in openssl In-Reply-To: <9A5E6F46-667F-4AD8-8B68-9EC6DA8BD707@oracle.com> References: <9A5E6F46-667F-4AD8-8B68-9EC6DA8BD707@oracle.com> Message-ID: <89A3CBA6-0719-4CBC-BFAE-A3AA20995C12@oracle.com> And done. This also pointed out a mistake in the man page code. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 15 Sep 2019, at 9:16 am, Dr Paul Dale wrote: > > The example is wrong. > > The KDF API changed recently to better match the way the rest of the project is moving. > I?ll update the example. > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 15 Sep 2019, at 7:28 am, Bhuvan Sharma > wrote: >> >> Hey all, >> I'm new to openssl community and I don't know much about it. I tried to use openssl on my linux machine. I clone openssl git repo and executed these commands as mentioned in the file "INSTALL": "./config", "make", "make test", "make install". It went alright. Then I tried an "EVP KEY Derivation" example from this link: https://wiki.openssl.org/index.php?title=EVP_Key_Derivation&redirect=no#targetText=HKDF%20was%20designed%20by%20Krawczyk,from%20the%20OpenSSL%20man%20pages . But it gives me some error for undeclared function. >> ~/openssl$ gcc -std=c99 test.c -o test.exe -l:libcrypto.a -pthread -ldl >> test.c: In function ?main?: >> test.c:12:17: warning: implicit declaration of function ?EVP_KDF_CTX_new_id?; did you mean ?EVP_KDF_CTX_new?? [-Wimplicit-function-declaration] >> if ((kctx = EVP_KDF_CTX_new_id(EVP_KDF_HKDF)) == NULL) { >> ^~~~~~~~~~~~~~~~~~ >> EVP_KDF_CTX_new >> test.c:12:36: error: ?EVP_KDF_HKDF? undeclared (first use in this function); did you mean ?EVP_PKEY_HKDF?? >> if ((kctx = EVP_KDF_CTX_new_id(EVP_KDF_HKDF)) == NULL) { >> ^~~~~~~~~~~~ >> EVP_PKEY_HKDF >> test.c:12:36: note: each undeclared identifier is reported only once for each function it appears in >> test.c:13:9: warning: implicit declaration of function ?error?; did you mean ?perror?? [-Wimplicit-function-declaration] >> error("EVP_KDF_CTX_new_id"); >> ^~~~~ >> perror >> test.c:15:9: warning: implicit declaration of function ?EVP_KDF_ctrl?; did you mean ?EVP_KDF_size?? [-Wimplicit-function-declaration] >> if (EVP_KDF_ctrl(kctx, EVP_KDF_CTRL_SET_MD, EVP_sha256()) <= 0) { >> ^~~~~~~~~~~~ >> EVP_KDF_size >> >> Is there any problem with the installation or am I missing something else? >> Your help is much appreciated. >> >> Thanks & Regards, >> Bhuvan Sharma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlosmaynard at gmail.com Sun Sep 15 11:05:49 2019 From: carlosmaynard at gmail.com (Carlos Maynard) Date: Sun, 15 Sep 2019 06:05:49 -0500 Subject: openssl smime/cms unable to handle binary encoded message? (header too long:asn1) In-Reply-To: References: Message-ID: Hello gentlemen, I am troubleshooting an issue with an AS2 setup, the error I'm getting is AS1_get_obect:header too long:asn1. Playing with another system, I was able to replicate the issue by switching the encoding from Base64 to Binary. Before i get a smart response... the trading partner can't switch the encoding from binary to base64,.. so here I am ;-) Apparently openssl assumes that all SMIME messages are base64 encoded, and balks when this is not the case? Basically the transmission is an encrypted and signed. The decryption goes well, but then the signature verification fails, the full error message is below. 139666245117592:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:asn1_lib.c:157: 139666245117592:error:0D0D106E:asn1 encoding routines:B64_READ_ASN1:decode error:asn_mime.c:192: 139666245117592:error:0D0D40CC:asn1 encoding routines:SMIME_read_ASN1:asn1 sig parse error:asn_mime.c:490: It looks like I'm not alone in this... https://superuser.com/questions/1097544/error-when-decompress-smime-file According to the link above... I should be able to discard the the headers and handle the binary body with openssl. Copying/Pasting from the link above... $ sed '1,/^\r$/d' suA97544.body $ openssl cms -uncompress -inform der -in suA97544.body Now, when I try this suggestion... sed does strip the MIME headers, but still when attempting to uncompress with openssl there is an error. Error reading S/MIME message 140081090963096:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1217: 140081090963096:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:386:Type=CMS_ContentInfo I am hoping I am just missing something here... obviously openssl is not my forte. :-) For illustration purposes, here is the original structure: content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=SHA-1; boundary="_=4094798051677677Sterling4094798051677677MOKO" --_=4094798051677677Sterling4094798051677677MOKO content-type: application/pkcs7-mime; smime-type=compressed-data; name=smime.p7m .... (Binary) --_=4094798051677677Sterling4094798051677677MOKO content-type: application/pkcs7-signature; name=EDIINTSIG.p7s .... (Binary) After sed... the structure looks like this... which fails to uncompress with openssl --_=4094798051677677Sterling4094798051677677MOKO content-type: application/pkcs7-mime; smime-type=compressed-data; name=smime.p7m .... (Binary) --_=4094798051677677Sterling4094798051677677MOKO content-type: application/pkcs7-signature; name=EDIINTSIG.p7s ... (Binary) openssl pkcs7 -in 5d7aa60750796.dat.3 -inform DER Last but not least, if I split the two parts, remove the boundary and content-type line... I can use pkcs7 to convert the binary content for each individual file, and I get this, but I'm not sure that this is what I think it is (the data what the next step would be. Talk about shooting in the dark. LoL. openssl pkcs7 -in 5d7aa60750796.dat.3 -inform DER -----BEGIN PKCS7----- MIHOBgsqhkiG9woBCRABCaCBvjCAAgEAMAoGCyqGSIb3CgEJEAMIMIAGCSqGSIb3 CgEHAaCAJIAEAnicBIGMc87PK0nNK9EtqSxItVJwLCjIyUxOLMnMz9N3dfHUjTA0 4uVKhirJTLFSsPH19/Z3dnMGSeblp6Qa6hqaJRsYGicaJ5oY6hoZWRgZmJuaWTi7 uTsGGzlAFNrxcvFyKQOBQoiHZ7ACEDkqhLgGhyj4ugYHO7q7KoDlXPwV/PxDFAKC /J2BwmAxABhSKacAAAAAAAA= -----END PKCS7----- I suspect this is a compressed version of the actual message, but I can't get any further. Any help, recommendations, thoughts would be greatly appreciated!! Is there a solid openssl implementation that can handle the binary encoded smime message? Thanks in advance! CM. -------------- next part -------------- An HTML attachment was scrubbed... URL: From malz at jetlan.com Sun Sep 15 11:32:40 2019 From: malz at jetlan.com (Mal) Date: Sun, 15 Sep 2019 21:02:40 +0930 Subject: 1.1.1d LD_LIBRARY_PATH In-Reply-To: <20190914055639.D291D40605C@ip-64-139-1-69.sjc.megapath.net> References: <20190914055639.D291D40605C@ip-64-139-1-69.sjc.megapath.net> Message-ID: <5cf617ef-76d5-95ce-ef35-31e2329fed3b@jetlan.com> On 14/09/2019 3:26 pm, Hal Murray wrote: > >> Would someone let me know how to add this path permanently, as currently i >> need to re-add on restart ? > > man ld, search for rpath > > Re-built with: ./config -Wl,-rpath,/os/openssl-1.1.1d Worked a treat. From jimmy.jung at slandala.com Sun Sep 15 13:58:37 2019 From: jimmy.jung at slandala.com (Jimmy Jung) Date: Sun, 15 Sep 2019 13:58:37 +0000 Subject: Role Separation Message-ID: <666901fc19f645568fa0670ce248c616@S12-MBX11-22.S12.local> I had been poking around the internet looking for implementations of Role Separation for OpenSSL (in this case in Centos). I thought I should ask here as well. By "role separation" I'm thinking that only PKI roles can perform OpenSSL commands and system admins are restricted from these operations. Thanks jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: From aerowolf at gmail.com Sun Sep 15 15:29:04 2019 From: aerowolf at gmail.com (Kyle Hamilton) Date: Sun, 15 Sep 2019 10:29:04 -0500 Subject: Role Separation In-Reply-To: <666901fc19f645568fa0670ce248c616@S12-MBX11-22.S12.local> References: <666901fc19f645568fa0670ce248c616@S12-MBX11-22.S12.local> Message-ID: OpenSSL is a toolkit, not a full implementation. More importantly, it is a library, so anyone who can link against it can perform all operations that the library can support, and the library has no concept of role separation built in. As such, the 'openssl' commandline tool allows the use of any of its subcommands by anyone who can run their executables. This generally includes 'root', which is also usually necessary for manipulating files (keys, certs, and CA cert chains) which are owned by system users, like 'apache'. There are many openssl subcommands which are useful for standard system and network administrators. s_client and s_server (to verify interoperability and connectivity), x509 (to figure out what's broken and see if it's something the PKI admin needs to deal with, in conjunction with the -noout and -text parameters), verify (to figure out what's wrong with a cert chain to make filing tickets for the pki admin more useful)... the only commands I can really think of off the top of my head that could be legitimately restricted are 'req' and 'ca'. Usually, the 'ca' command is limited by access to the CA key. 'req' generates a new certificate signing request, but doesn't generate a new certificate. The operations for a PKI admin should in all cases include "generate your request, then send the request that you just generated" rather than "submit some request that some other schlub generated", which mitigates that particular potential disaster. It might be possible to limit the execution of openssl subcommands using SELinux roles and labels, but I don't think anyone's audited the subcommands looking for functionality that should be limited to one role or another. The closest that's been done has been for the FIPS validation, and (to my uncertain understanding) even that applies pretty much only to the building and installation of the module. If you do perform such an audit, I'd love to see your work. (n.b. I'm not a member of the OpenSSL team, so my opinions are mgmy own and no one else's.) -Kyle H On Sun, Sep 15, 2019, 09:06 Jimmy Jung wrote: > I had been poking around the internet looking for implementations of Role > Separation for OpenSSL (in this case in Centos). I thought I should ask > here as well. > > > > By ?role separation? I?m thinking that only PKI roles can perform OpenSSL > commands and system admins are restricted from these operations. > > > > Thanks > > > > jimmy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Sep 16 07:47:58 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 16 Sep 2019 08:47:58 +0100 Subject: Problem in trying EVP Key Derivation example in openssl In-Reply-To: References: Message-ID: On 14/09/2019 22:28, Bhuvan Sharma wrote: > Hey all, > I'm new to openssl community and I don't know much about it. I tried to use > openssl on my linux machine. I clone openssl git repo and executed these > commands as mentioned in the file "INSTALL": "./config", "make", "make test", > "make install". It went alright. Then I tried an "EVP KEY Derivation" example > from this Please note that the KDF API is only in the dev version of OpenSSL so the API is not yet stable. For stable versions you have to use the older EVP_PKEY_dervie APIs. Matt > link:?https://wiki.openssl.org/index.php?title=EVP_Key_Derivation&redirect=no#targetText=HKDF%20was%20designed%20by%20Krawczyk,from%20the%20OpenSSL%20man%20pages. > But it gives me some error for undeclared function.? > ~/openssl$ gcc -std=c99 test.c -o test.exe -l:libcrypto.a -pthread -ldl > test.c: In function ?main?: > test.c:12:17: warning: implicit declaration of function ?EVP_KDF_CTX_new_id?; > did you mean ?EVP_KDF_CTX_new?? [-Wimplicit-function-declaration] > ? ? ?if ((kctx = EVP_KDF_CTX_new_id(EVP_KDF_HKDF)) == NULL) { > ? ? ? ? ? ? ? ? ?^~~~~~~~~~~~~~~~~~ > ? ? ? ? ? ? ? ? ?EVP_KDF_CTX_new > test.c:12:36: error: ?EVP_KDF_HKDF? undeclared (first use in this function); did > you mean ?EVP_PKEY_HKDF?? > ? ? ?if ((kctx = EVP_KDF_CTX_new_id(EVP_KDF_HKDF)) == NULL) { > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^~~~~~~~~~~~ > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? EVP_PKEY_HKDF > test.c:12:36: note: each undeclared identifier is reported only once for each > function it appears in > test.c:13:9: warning: implicit declaration of function ?error?; did you mean > ?perror?? [-Wimplicit-function-declaration] > ? ? ? ? ?error("EVP_KDF_CTX_new_id"); > ? ? ? ? ?^~~~~ > ? ? ? ? ?perror > test.c:15:9: warning: implicit declaration of function ?EVP_KDF_ctrl?; did you > mean ?EVP_KDF_size?? [-Wimplicit-function-declaration] > ? ? ?if (EVP_KDF_ctrl(kctx, EVP_KDF_CTRL_SET_MD, EVP_sha256()) <= 0) { > ? ? ? ? ?^~~~~~~~~~~~ > ? ? ? ? ?EVP_KDF_size > > Is there any problem with the installation or am I missing something else? > Your help is much appreciated. > > Thanks &?Regards, > Bhuvan Sharma From hkario at redhat.com Mon Sep 16 12:14:10 2019 From: hkario at redhat.com (Hubert Kario) Date: Mon, 16 Sep 2019 14:14:10 +0200 Subject: Truncated Hmac and supported group extension in openssl1.1.1 In-Reply-To: References: Message-ID: <1686808.W9coeaaQIS@pintsize.usersys.redhat.com> On Friday, 13 September 2019 16:37:23 CEST Manish Patidar wrote: > Hi > > Is truncated hmac extension is supported in openssl1.1.1 ? no > is TLS1. 2 and lower TLS version supports supported group extension for > Finite Field GROUPS (DHE) ? I'm assuming the question is still about openssl 1.1.1, not the protocol itself; the answer is then no -- 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 Michael.Wojcik at microfocus.com Mon Sep 16 13:40:37 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 16 Sep 2019 13:40:37 +0000 Subject: Linker errors when trying to build OpenSSL with MD2 and RC5 support In-Reply-To: References: , , , , , , Message-ID: Did you read my previous response, where I listed the relevant Configure options? Be sure to expand included text, if you're using one of those braindead MUAs which hide it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peters at qnext.com Mon Sep 16 14:44:01 2019 From: peters at qnext.com (Peter Sui) Date: Mon, 16 Sep 2019 10:44:01 -0400 Subject: building openssl-1.1.1d with "enable-deprecated" Message-ID: Hi, From the openssl website, I got the folloeing instruction: " Access to deprecated functions/macros has been removed by default. To enable access you must do two things. 1) Build OpenSSL with deprecation support (pass "enable-deprecated" as an argument to config) 2) Applications must define "OPENSSL_USE_DEPRECATED" before including OpenSSL header files. " But, after I followed the instructions, it did not work. I searched all the files(.h, .cpp, .c), I did not see the "OPENSSL_USE_DEPRECATED" anywhere. And in the make file generated, I found it's using the flag -D"_CRT_SECURE_NO_DEPRECATE", does it mean no deprecated functions available in the library built? I also compared all the binary and header files between the build without "enable-deprecated" and the build with "enable-deprecated", there is no difference. The command I used is: perl Configure VC-WIN32 enable-deprecated --prefix=T:\openssl-%OPENSSL_VERSION%-32bit-release-DLL-VS2015 nmake Thank you inadvance! Peter Sui -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Sep 16 14:52:46 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 16 Sep 2019 15:52:46 +0100 Subject: building openssl-1.1.1d with "enable-deprecated" In-Reply-To: References: Message-ID: <45ac8ed4-35e4-23d2-683b-42d5f09b7d2b@openssl.org> On 16/09/2019 15:44, Peter Sui wrote: > Hi, > ? ? ?? From the openssl website, I got the folloeing instruction: > " > Access to deprecated functions/macros has been removed by default. To enable > access you must do two things. 1) Build OpenSSL with deprecation support (pass > "enable-deprecated" as an argument to config) 2) Applications must define > "OPENSSL_USE_DEPRECATED" before including OpenSSL header files. > " > But, after I followed the instructions, it did not work. I searched all the > files(.h, .cpp, .c), I did not see the?"OPENSSL_USE_DEPRECATED"? anywhere. And > in the make file generated, I found it's using the > flag?-D"_CRT_SECURE_NO_DEPRECATE", does it mean no deprecated functions > available in the library built?? I also compared all the binary and header files > between the build without "enable-deprecated" and the build > with?"enable-deprecated", there is no difference. > The command I used is: > perl Configure VC-WIN32 enable-deprecated > --prefix=T:\openssl-%OPENSSL_VERSION%-32bit-release-DLL-VS2015 > nmake > That CHANGES entry is incorrect and out-of-date. It should probably be removed. The original CHANGES entry said this: *) config has been changed so that by default OPENSSL_NO_DEPRECATED is used. Access to deprecated functions can be re-enabled by running config with "enable-deprecated". In addition applications wishing to use deprecated functions must define OPENSSL_USE_DEPRECATED. Note that this new behaviour will, by default, disable some transitive includes that previously existed in the header files (e.g. ec.h will no longer, by default, include bn.h) [Matt Caswell] That CHANGES entry was added while 1.1.0 was being developed. However before 1.1.0 was released we changed our mind and added this CHANGES entry: *) Revert default OPENSSL_NO_DEPRECATED setting. Instead OpenSSL continues to support deprecated interfaces in default builds. However, applications are strongly advised to compile their source files with -DOPENSSL_API_COMPAT=0x10100000L, which hides the declarations of all interfaces deprecated in 0.9.8, 1.0.0 or the 1.1.0 releases. In environments in which all applications have been ported to not use any deprecated interfaces OpenSSL's Configure script should be used with the --api=1.1.0 option to entirely remove support for the deprecated features from the library and unconditionally disable them in the installed headers. Essentially the same effect can be achieved with the "no-deprecated" argument to Configure, except that this will always restrict the build to just the latest API, rather than a fixed API version. As applications are ported to future revisions of the API, they should update their compile-time OPENSSL_API_COMPAT define accordingly, but in most cases should be able to continue to compile with later releases. The OPENSSL_API_COMPAT versions for 1.0.0, and 0.9.8 are 0x10000000L and 0x00908000L, respectively. However those versions did not support the OPENSSL_API_COMPAT feature, and so applications are not typically tested for explicit support of just the undeprecated features of either release. [Viktor Dukhovni] Regards Matt From peters at qnext.com Mon Sep 16 15:09:44 2019 From: peters at qnext.com (Peter Sui) Date: Mon, 16 Sep 2019 11:09:44 -0400 Subject: building openssl-1.1.1d with "enable-deprecated" In-Reply-To: <45ac8ed4-35e4-23d2-683b-42d5f09b7d2b@openssl.org> References: <45ac8ed4-35e4-23d2-683b-42d5f09b7d2b@openssl.org> Message-ID: Hi Matt, So you are saying configuring with "enable-deprecated" or not won't make the build different, they are all actually support the deprecated functions, right ? If yes, then in my application , if I have "OPENSSL_USE_DEPRECATED" defined, the depecated functions in my application should still work, right? But it does not work. And as I imagine, in the openssl header files(after a successful build), it should have some "#if defines OPENSSL_USE_DEPRECATED" like statement, but I don't see it anywhere, can you tell me how it works? Thanks! Peter On Mon, Sep 16, 2019 at 10:52 AM Matt Caswell wrote: > > > On 16/09/2019 15:44, Peter Sui wrote: > > Hi, > > From the openssl website, I got the folloeing instruction: > > " > > Access to deprecated functions/macros has been removed by default. To > enable > > access you must do two things. 1) Build OpenSSL with deprecation support > (pass > > "enable-deprecated" as an argument to config) 2) Applications must define > > "OPENSSL_USE_DEPRECATED" before including OpenSSL header files. > > " > > But, after I followed the instructions, it did not work. I searched all > the > > files(.h, .cpp, .c), I did not see the "OPENSSL_USE_DEPRECATED" > anywhere. And > > in the make file generated, I found it's using the > > flag -D"_CRT_SECURE_NO_DEPRECATE", does it mean no deprecated functions > > available in the library built? I also compared all the binary and > header files > > between the build without "enable-deprecated" and the build > > with "enable-deprecated", there is no difference. > > The command I used is: > > perl Configure VC-WIN32 enable-deprecated > > --prefix=T:\openssl-%OPENSSL_VERSION%-32bit-release-DLL-VS2015 > > nmake > > > > That CHANGES entry is incorrect and out-of-date. It should probably be > removed. > The original CHANGES entry said this: > > *) config has been changed so that by default OPENSSL_NO_DEPRECATED is > used. > Access to deprecated functions can be re-enabled by running config > with > "enable-deprecated". In addition applications wishing to use > deprecated > functions must define OPENSSL_USE_DEPRECATED. Note that this new > behaviour > will, by default, disable some transitive includes that previously > existed > in the header files (e.g. ec.h will no longer, by default, include > bn.h) > [Matt Caswell] > > That CHANGES entry was added while 1.1.0 was being developed. However > before > 1.1.0 was released we changed our mind and added this CHANGES entry: > > *) Revert default OPENSSL_NO_DEPRECATED setting. Instead OpenSSL > continues to support deprecated interfaces in default builds. > However, applications are strongly advised to compile their > source files with -DOPENSSL_API_COMPAT=0x10100000L, which hides > the declarations of all interfaces deprecated in 0.9.8, 1.0.0 > or the 1.1.0 releases. > > In environments in which all applications have been ported to > not use any deprecated interfaces OpenSSL's Configure script > should be used with the --api=1.1.0 option to entirely remove > support for the deprecated features from the library and > unconditionally disable them in the installed headers. > Essentially the same effect can be achieved with the "no-deprecated" > argument to Configure, except that this will always restrict > the build to just the latest API, rather than a fixed API > version. > > As applications are ported to future revisions of the API, > they should update their compile-time OPENSSL_API_COMPAT define > accordingly, but in most cases should be able to continue to > compile with later releases. > > The OPENSSL_API_COMPAT versions for 1.0.0, and 0.9.8 are > 0x10000000L and 0x00908000L, respectively. However those > versions did not support the OPENSSL_API_COMPAT feature, and > so applications are not typically tested for explicit support > of just the undeprecated features of either release. > [Viktor Dukhovni] > > Regards > > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Sep 16 15:16:28 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 16 Sep 2019 16:16:28 +0100 Subject: building openssl-1.1.1d with "enable-deprecated" In-Reply-To: References: <45ac8ed4-35e4-23d2-683b-42d5f09b7d2b@openssl.org> Message-ID: <93479adb-2448-77d7-183c-8b5651357956@openssl.org> On 16/09/2019 16:09, Peter Sui wrote: > Hi Matt, > ? ? ? ? So you are saying configuring with "enable-deprecated" or not won't make > the build different, they are all actually support the deprecated functions, > right ? Right. > If yes, then in my application , if? I have "OPENSSL_USE_DEPRECATED" > defined, the depecated functions in my application should still work, right? You don't need OPENSSL_USE_DEPRECATED at all. All of that code was removed when we changed our mind. It doesn't exist at all in the codebase today. > But it does not work. What exactly does not work? What function are you trying to call? Matt > And as I imagine, in the openssl header files(after a > successful build), it should have some "#if defines?OPENSSL_USE_DEPRECATED" like > statement, but I don't see it anywhere, can you tell me how it works? > > Thanks! > > Peter > > On Mon, Sep 16, 2019 at 10:52 AM Matt Caswell > wrote: > > > > On 16/09/2019 15:44, Peter Sui wrote: > > Hi, > > ? ? ?? From the openssl website, I got the folloeing instruction: > > " > > Access to deprecated functions/macros has been removed by default. To enable > > access you must do two things. 1) Build OpenSSL with deprecation support (pass > > "enable-deprecated" as an argument to config) 2) Applications must define > > "OPENSSL_USE_DEPRECATED" before including OpenSSL header files. > > " > > But, after I followed the instructions, it did not work. I searched all the > > files(.h, .cpp, .c), I did not see the?"OPENSSL_USE_DEPRECATED"? anywhere. And > > in the make file generated, I found it's using the > > flag?-D"_CRT_SECURE_NO_DEPRECATE", does it mean no deprecated functions > > available in the library built?? I also compared all the binary and header > files > > between the build without "enable-deprecated" and the build > > with?"enable-deprecated", there is no difference. > > The command I used is: > > perl Configure VC-WIN32 enable-deprecated > > --prefix=T:\openssl-%OPENSSL_VERSION%-32bit-release-DLL-VS2015 > > nmake > > > > That CHANGES entry is incorrect and out-of-date. It should probably be removed. > The original CHANGES entry said this: > > ? *) config has been changed so that by default OPENSSL_NO_DEPRECATED is used. > ? ? ?Access to deprecated functions can be re-enabled by running config with > ? ? ?"enable-deprecated". In addition applications wishing to use deprecated > ? ? ?functions must define OPENSSL_USE_DEPRECATED. Note that this new behaviour > ? ? ?will, by default, disable some transitive includes that previously existed > ? ? ?in the header files (e.g. ec.h will no longer, by default, include bn.h) > ? ? ?[Matt Caswell] > > That CHANGES entry was added while 1.1.0 was being developed. However before > 1.1.0 was released we changed our mind and added this CHANGES entry: > > ? *) Revert default OPENSSL_NO_DEPRECATED setting.? Instead OpenSSL > ? ? ?continues to support deprecated interfaces in default builds. > ? ? ?However, applications are strongly advised to compile their > ? ? ?source files with -DOPENSSL_API_COMPAT=0x10100000L, which hides > ? ? ?the declarations of all interfaces deprecated in 0.9.8, 1.0.0 > ? ? ?or the 1.1.0 releases. > > ? ? ?In environments in which all applications have been ported to > ? ? ?not use any deprecated interfaces OpenSSL's Configure script > ? ? ?should be used with the --api=1.1.0 option to entirely remove > ? ? ?support for the deprecated features from the library and > ? ? ?unconditionally disable them in the installed headers. > ? ? ?Essentially the same effect can be achieved with the "no-deprecated" > ? ? ?argument to Configure, except that this will always restrict > ? ? ?the build to just the latest API, rather than a fixed API > ? ? ?version. > > ? ? ?As applications are ported to future revisions of the API, > ? ? ?they should update their compile-time OPENSSL_API_COMPAT define > ? ? ?accordingly, but in most cases should be able to continue to > ? ? ?compile with later releases. > > ? ? ?The OPENSSL_API_COMPAT versions for 1.0.0, and 0.9.8 are > ? ? ?0x10000000L and 0x00908000L, respectively.? However those > ? ? ?versions did not support the OPENSSL_API_COMPAT feature, and > ? ? ?so applications are not typically tested for explicit support > ? ? ?of just the undeprecated features of either release. > ? ? ?[Viktor Dukhovni] > > Regards > > Matt > From Michael.Wojcik at microfocus.com Mon Sep 16 15:05:43 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 16 Sep 2019 15:05:43 +0000 Subject: building openssl-1.1.1d with "enable-deprecated" In-Reply-To: References: Message-ID: Matt has answered the main question, but as an aside: -D"_CRT_SECURE_NO_DEPRECATE" suppresses warning messages from Microsoft's Visual C compiler for using various standard C library functions, rather than using the optional "secure" ones (a misnomer, as they are at best somewhat easier to use safely) added with C99 (in Appendix K of the C standard, I think; I'm traveling and don't have my copy handy). It has nothing to do with OpenSSL APIs, deprecated or otherwise; it just reduces noise from the Microsoft compiler. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peters at qnext.com Mon Sep 16 15:26:48 2019 From: peters at qnext.com (Peter Sui) Date: Mon, 16 Sep 2019 11:26:48 -0400 Subject: building openssl-1.1.1d with "enable-deprecated" In-Reply-To: References: Message-ID: Hi Matt, I said " It does not work" means, after I build the open-ssl1.1.1d with or without the "enable-deprecated" configuration, then use the library, header files in my application as before with the older version(1.0.2t), then my build failed, the errors are like: Error C3861 'HMAC_CTX_init': identifier not found Error C3861 'HMAC_CTX_cleanup': identifier not found and more related to some struct def difference. But as I imagine, it should not happen, right ? Peter On Mon, Sep 16, 2019 at 11:17 AM Michael Wojcik < Michael.Wojcik at microfocus.com> wrote: > Matt has answered the main question, but as an aside: > -D"_CRT_SECURE_NO_DEPRECATE" suppresses warning messages from Microsoft's > Visual C compiler for using various standard C library functions, rather > than using the optional "secure" ones (a misnomer, as they are at best > somewhat easier to use safely) added with C99 (in Appendix K of the C > standard, I think; I'm traveling and don't have my copy handy). It has > nothing to do with OpenSSL APIs, deprecated or otherwise; it just reduces > noise from the Microsoft compiler. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Sep 16 15:38:03 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 16 Sep 2019 16:38:03 +0100 Subject: building openssl-1.1.1d with "enable-deprecated" In-Reply-To: References: Message-ID: On 16/09/2019 16:26, Peter Sui wrote: > Hi Matt,? > ? ? ?? I said " It does not work" means, after I build the open-ssl1.1.1d with > or without the "enable-deprecated" configuration, then use the library, header > files in my application as before with the older version(1.0.2t), then my build > failed, the errors are like: > Error?C3861?'HMAC_CTX_init': identifier not found > Error?C3861?'HMAC_CTX_cleanup': identifier not found > and more related to some struct def difference. > But as I imagine, it should not happen, right ? Ah - right. I understand your problem. 1.1.x is not source compatible with 1.0.x regardless of enabling/disabling deprecated functions. Some stuff just changed. Importantly most structures became opaque, so it is no longer possible to access the internal fields. An implication of this is that you can longer stack allocate objects based on these structures any more (because the compiler knows nothing about the size of the structure). So instead of this: HMAC_CTX ctx; You instead have to declare it as a pointer: HMAC_CTX *ctx; Then you allocate a ctx like this: ctx = HMAC_CTX_new(); And later free it: HMAC_CTX_free(); The same thing applies to lots of other structures. Since it is no longer possible to stack allocate an HMAC_CTX this makes functions like HMAC_CTX_init() and HMAC_CTX_cleanup() redundant because they only make sense when working with stack allocated structures - therefore they were removed completely. Matt > > Peter > > On Mon, Sep 16, 2019 at 11:17 AM Michael Wojcik > wrote: > > Matt has answered the main question, but as an aside: > -D"_CRT_SECURE_NO_DEPRECATE" suppresses warning messages from Microsoft's > Visual C compiler for using various standard C library functions, rather > than using the optional "secure" ones (a misnomer, as they are at best > somewhat easier to use safely) added with C99 (in Appendix K of the C > standard, I think; I'm traveling and don't have my copy handy). It has > nothing to do with OpenSSL APIs, deprecated or otherwise; it just reduces > noise from the Microsoft compiler. > From openssl at jordan.maileater.net Mon Sep 16 18:59:30 2019 From: openssl at jordan.maileater.net (Jordan Brown) Date: Mon, 16 Sep 2019 18:59:30 +0000 Subject: Role Separation In-Reply-To: References: <666901fc19f645568fa0670ce248c616@S12-MBX11-22.S12.local> Message-ID: <0101016d3b71b573-4f73e595-2433-47cf-9be6-a145be9130b6-000000@us-west-2.amazonses.com> On 9/15/2019 8:29 AM, Kyle Hamilton wrote: > OpenSSL is a toolkit, not a full implementation.? More importantly, it > is a library, so anyone who can link against it can perform all > operations that the library can support, and the library has no > concept of role separation built in. Still more importantly, almost everything OpenSSL does is just math and file manipulation.? S_client and s_server add basic network operations.? There's probably some low-level goop for hardware acceleration, but that's just acceleration. You can write a program to do those things without needing to involve OpenSSL, so restrictions on OpenSSL per se aren't very interesting. The way to restrict PKI operations (in a simple configuration) is through file and directory permissions on the data involved. -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdrotter at us.ibm.com Tue Sep 17 17:57:12 2019 From: pdrotter at us.ibm.com (Neptune) Date: Tue, 17 Sep 2019 10:57:12 -0700 (MST) Subject: Cannot find access to CRL flags in 1.1.x Message-ID: <1568743032904-0.post@n7.nabble.com> Migrating code base from 1.0.2 to 1.1.1c and have one last issue I cannot find a solution for: if (crl->flags & EXFLAG_CRITICAL) X509_CRL structure is opaque and I cannot access the flags member, however I cannot find any API call to retrieve the flags value. Thanks for any help/guidance, Paul -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From chitrang.srivastava at gmail.com Wed Sep 18 09:03:03 2019 From: chitrang.srivastava at gmail.com (Chitrang Srivastava) Date: Wed, 18 Sep 2019 14:33:03 +0530 Subject: DH group cipher suites getting rejected Message-ID: Hi, Why google rejected DH ciphers suites, I am trying *openssl s_client -cipher 'DHE-RSA-AES128-GCM-SHA256' -connect www.google.com:443 * However if I try ECDHE, it works fine. Is DHE only cipher suites less common now ? I believe its responsibility of server to generate DHparam of large enough size. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Sep 18 12:30:44 2019 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 18 Sep 2019 12:30:44 +0000 Subject: DH group cipher suites getting rejected In-Reply-To: References: Message-ID: <99E1C7D7-1B57-4D0C-AED6-DCEB8A699AA8@akamai.com> * However if I try ECDHE, it works fine. Is DHE only cipher suites less common now ? * I believe its responsibility of server to generate DHparam of large enough size. Yes, DHE has dropped because it is hard to get right, and it takes more CPU cycles than ECDHE. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Sep 18 18:58:58 2019 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 18 Sep 2019 18:58:58 +0000 Subject: Proposed change to linux kernel about random numbers Message-ID: <44C60BF7-7F03-4337-8A41-6CEAC1A05813@akamai.com> Please take a look at https://lore.kernel.org/lkml/CAHk-=wiGg-G8JFJ=R7qf0B+UtqA_Weouk6v+McmfsLJLRq6AKA at mail.gmail.com/ and consider giving your comments. TL;DR: see the comment below. + * Hacky workaround for the fact that some processes + * ask for truly secure random numbers and absolutely want + * to wait for the entropy pool to fill, and others just + * do "getrandom(0)" to get some ad-hoc random numbers. + * + * If you're generating a secure key, you'd better ask for + * more than 128 bits of randomness. Otherwise it's not + * really all that secure by definition. + * + * We should add a GRND_SECURE flag so that people can state + * this "I want secure random numbers" explicitly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Sep 18 20:50:16 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 18 Sep 2019 22:50:16 +0200 Subject: Proposed change to linux kernel about random numbers In-Reply-To: <44C60BF7-7F03-4337-8A41-6CEAC1A05813@akamai.com> References: <44C60BF7-7F03-4337-8A41-6CEAC1A05813@akamai.com> Message-ID: <4f285794-b87a-a397-f8c9-82a63baaf485@wisemo.com> On 18/09/2019 20:58, Salz, Rich via openssl-users wrote: > > Please take a look at > https://lore.kernel.org/lkml/CAHk-=wiGg-G8JFJ=R7qf0B+UtqA_Weouk6v+McmfsLJLRq6AKA at mail.gmail.com/ > and consider giving your comments. > > TL;DR:? see the comment below. > > + * Hacky workaround for the fact that some processes > > + * ask for truly secure random numbers and absolutely want > > + * to wait for the entropy pool to fill, and others just > > + * do "getrandom(0)" to get some ad-hoc random numbers. > > + * > > + * If you're generating a secure key, you'd better ask for > > + * more than 128 bits of randomness. Otherwise it's not > > + * really all that secure by definition. > > + * > > + * We should add a GRND_SECURE flag so that people can state > > + * this "I want secure random numbers" explicitly. > Well, I guess that comes from library authors suddenly ignoring proper usage of the original *random* API definitions, as well as all related compatibility needs. Until recently, the rules were clear: 1. If a program or library wanted seeding or bits for generating long ? term keys and was willing to wait, it would use /dev/random or (if ? in both running kernel and loaded libc) getrandom(2) with GRND_RANDOM ? (and soon GRND_SECURE).? This includes waiting for the OS to say it ? has actually gathered entropy etc. 2. If a program or library wanted to set up an internal RNG that can ? be reseeded later it would use /dev/urandom or (if in both running ? kernel and loaded libc) getrandom(2) with neither GRND_RANDOM or ? GRND_SECURE, nor waiting for the kernel to estimate having entropy. ? Then reseed later when OS has more entropy, but not so often as to ? keep the system dry. 3. If a multipurpose library or tool (such as OpenSSL and the openssl ? command line tool) uses the random bits in both ways, it needs to ? pass the choice onto the caller, like OpenSSL 1.0.x did with the ? difference between RAND_pseudo_bytes and RAND_bytes. ? For example, a TLS or SSH implementation can use the weaker entropy ? source to start handling incoming calls (with session keys) soon ? after boot, while a tool to set up initial private keys at first ? boot would need to wait for the stronger entropy source (which may ? in fact get initial randomness over such an encrypted early ? connection!). 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 mann.patidar at gmail.com Thu Sep 19 06:47:51 2019 From: mann.patidar at gmail.com (Manish Patidar) Date: Thu, 19 Sep 2019 12:17:51 +0530 Subject: Doubts in the fix of CVE-2019-1559 Message-ID: Hi This vulnerability is fixed based on pid of process. Currently we are geting pid only where pthread is enabled, does it mean that this vulnerability does not impact to other environment like Windows etc.? Regards Manish -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Sep 19 08:13:46 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 19 Sep 2019 09:13:46 +0100 Subject: Doubts in the fix of CVE-2019-1559 In-Reply-To: References: Message-ID: On 19/09/2019 07:47, Manish Patidar wrote: > Hi > This vulnerability is fixed based on pid of process. Currently we are geting pid > only? where pthread is enabled,? does it mean that this vulnerability does not > impact to other environment like Windows etc.? CVE-2019-1559 has nothing to do with pids. It is a padding oracle that can occur if 0 byte records are received. Perhaps you meant CVE-2019-1549? This is related to how we reseed the random number generator in the event of a "fork". Since windows lacks the capability to do fork it is not a problem on that platform. Matt From dfulger at gmx.com Thu Sep 19 18:17:24 2019 From: dfulger at gmx.com (Dan Fulger) Date: Thu, 19 Sep 2019 20:17:24 +0200 Subject: An idiosyncratic port of OpenSSL 1.1.1d to OS/400 ILE Message-ID: An HTML attachment was scrubbed... URL: From llf at e-code.net Sat Sep 21 06:45:19 2019 From: llf at e-code.net (llf at e-code.net) Date: Sat, 21 Sep 2019 14:45:19 +0800 Subject: Sometimes my client can't receive data References: <2019092114054202622123@e-code.net>, <2019092114313033022729@e-code.net> Message-ID: <2019092114451906534930@e-code.net> Hello, everyone ! I'm using openssl as client in blocking mode , i have a problem . Sometimes my program can't receive data , and acctually server has been sent the data to me. I can only receive the data by sending another request . Then the data i expected arrived with a new data sent by server . Below is my code ------------------------------------------------------------------------------ bool can_read() { struct timeval tv = {0 , 100}; FD_ZERO(&m_rfds); FD_SET(m_socket.fd(), &m_rfds); int ret = select( m_socket.fd()+1, &m_rfds , NULL, NULL, &tv); return ret > 0 ; } //this is the main process int try_receive(char * buf , int len ) { if( !can_read()) return -1; return SSL_read(m_ssl, buf, len); } ------------------------------------------------------------------------------- I'd really appreciate if you could tell me what's wrong with this code . -------------- next part -------------- An HTML attachment was scrubbed... URL: From llf at e-code.net Mon Sep 23 02:50:09 2019 From: llf at e-code.net (=?UTF-8?B?6Lev6L+e5bOw?=) Date: Mon, 23 Sep 2019 10:50:09 +0800 Subject: =?UTF-8?B?TXkgY2xpZW50IGNhbiBub3QgcmVjZWl2ZSBkYXRhIGluIGJsb2NraW5nIG1vZGU=?= Message-ID: <5ead1a33-87a3-4f8d-b6b4-5da52baaf9ad.llf@e-code.net> Hello I'm using openssl as client in blocking mode , i have a problem . Sometimes my program can't receive data , and acctually server has been sent the data to me. I can only receive the data by sending another request . Then the data i expected arrived with a new data sent by server . ------------------------------------------------------------------------------ bool can_read() { if(SSL_pending(m_ssl)) return true; struct timeval tv = {0 , 100}; FD_ZERO(&m_rfds); FD_SET(m_socket.fd(), &m_rfds); int ret = select( m_socket.fd()+1, &m_rfds , NULL, NULL, &tv); return ret > 0 ; } //this is the main process int try_receive(char * buf , int len ) { if( !can_read()) return -1; return SSL_read(m_ssl, buf, len); } ------------------------------------------------------------------------------- Above is my code , my program get `false` from `can_read` although the server has sent response data I really appreciate your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacastro at kstros.com Mon Sep 23 17:21:38 2019 From: jacastro at kstros.com ((KSTROS) - Jayron Alberth Costa Castro) Date: Mon, 23 Sep 2019 17:21:38 +0000 Subject: otherName structure Message-ID: <1569259297271.75108@kstros.com> Hi friends, I need some help, because I need to create within the subjectAltName structure three structures like otherName and I can't create it via openssl command line. I currently use version 1.1.1d and wanted help in this regard. I take the opportunity to know how I can capture the content of fields provided via the attributes structure, to assemble the requested structure, who can help, I will be grateful !!? Att, JAYRON ALBERTH COSTA CASTRO Network Infrastructure Engineer Kstros Treinamento e Tecnologia Ltda Cel.: +55 (85) 98162-3076 skype: jayron_castro jacastro at kstros.com [rodape] -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Mon Sep 23 17:50:20 2019 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 23 Sep 2019 20:50:20 +0300 Subject: otherName structure In-Reply-To: <1569259297271.75108@kstros.com> References: <1569259297271.75108@kstros.com> Message-ID: Hello, There is some documentation in doc/man5/x509v3_config.pod and apropos commands. On Mon, Sep 23, 2019 at 8:42 PM (KSTROS) - Jayron Alberth Costa Castro < jacastro at kstros.com> wrote: > Hi friends, I need some help, because I need to create within the > subjectAltName structure three structures like otherName and I can't create > it via openssl command line. I currently use version 1.1.1d and wanted help > in this regard. > > I take the opportunity to know how I can capture the content of fields > provided via the attributes structure, to assemble the requested structure, > who can help, I will be grateful !!? > > > Att, > > *JAYRON ALBERTH COSTA CASTRO* > *Network Infrastructure Engineer* > *Kstros Treinamento e Tecnologia Ltda* > > Cel.: +55 (85) 98162-3076 > skype: jayron_castro > jacastro at kstros.com > > [image: rodape] > > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacastro at kstros.com Mon Sep 23 17:56:17 2019 From: jacastro at kstros.com ((KSTROS) - Jayron Alberth Costa Castro) Date: Mon, 23 Sep 2019 17:56:17 +0000 Subject: otherName structure In-Reply-To: References: <1569259297271.75108@kstros.com>, Message-ID: <1569261376290.58559@kstros.com> ?I have already read the documentation, but it only shows how to insert a single otherName field and so I have done several tests, without success. :(? JAYRON ALBERTH COSTA CASTRO Network Infrastructure Engineer Kstros Treinamento e Tecnologia Ltda Cel.: +55 (85) 98162-3076 skype: jayron_castro jacastro at kstros.com [rodape] ________________________________ De: Dmitry Belyavsky Enviado: segunda-feira, 23 de setembro de 2019 14:50 Para: (KSTROS) - Jayron Alberth Costa Castro Cc: openssl-users at openssl.org Assunto: Re: otherName structure Hello, There is some documentation in doc/man5/x509v3_config.pod and apropos commands. On Mon, Sep 23, 2019 at 8:42 PM (KSTROS) - Jayron Alberth Costa Castro > wrote: Hi friends, I need some help, because I need to create within the subjectAltName structure three structures like otherName and I can't create it via openssl command line. I currently use version 1.1.1d and wanted help in this regard. I take the opportunity to know how I can capture the content of fields provided via the attributes structure, to assemble the requested structure, who can help, I will be grateful !!? Att, JAYRON ALBERTH COSTA CASTRO Network Infrastructure Engineer Kstros Treinamento e Tecnologia Ltda Cel.: +55 (85) 98162-3076 skype: jayron_castro jacastro at kstros.com [rodape] -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Sep 23 18:00:00 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 23 Sep 2019 14:00:00 -0400 Subject: otherName structure In-Reply-To: <1569261376290.58559@kstros.com> References: <1569259297271.75108@kstros.com> <1569261376290.58559@kstros.com> Message-ID: <20190923180000.GK21772@straasha.imrryr.org> On Mon, Sep 23, 2019 at 05:56:17PM +0000, (KSTROS) - Jayron Alberth Costa Castro wrote: > I have already read the documentation, but it only shows how to insert a > single otherName field and so I have done several tests, without success. subjectAltName = @altnames [altnames] otherName.1 = ... otherName.2 = ... ... -- Viktor. From Matthias.St.Pierre at ncp-e.com Mon Sep 23 18:26:01 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 23 Sep 2019 18:26:01 +0000 Subject: OpenSSL 1.1.1d: test 20-test_enc.t fails if zlib is enabled Message-ID: Hello, since we got a few bug reports by now about this issue on GitHub, I thought it might be a good idea to spread the information a little bit: It is a known issue that the 20-test_enc.t test fails in OpenSSL version 1.1.1d if zlib support is enabled (see [1]). Meanwhile, the bug has been fixed on master and the OpenSSL_1_1_1-stable branch (see [2]). The test error can be ignored, if you don't use the `openssl zlib` command, resp. the BIO_f_zlib() filter BIO. However, if you need a fix for it before the next official release, you have two options: - Apply the patch 86ed78676c66 manually to your copy of 1.1.1d (see [3]). - Update to the tip of the OpenSSL_1_1_1-stable branch (see [4]). Regards, Matthias [1] https://github.com/openssl/openssl/issues/9866 [2] https://github.com/openssl/openssl/pull/9877 [3] https://github.com/openssl/openssl/commit/86ed78676c660b553696cc10c682962522dfeb6c [4] https://github.com/openssl/openssl/commits/OpenSSL_1_1_1-stable From hanjideng at gmail.com Tue Sep 24 07:54:17 2019 From: hanjideng at gmail.com (JD H) Date: Tue, 24 Sep 2019 15:54:17 +0800 Subject: Fwd: static link segmentation fault In-Reply-To: References: Message-ID: * Hi:* *I static compile opensslv1.1.1 on Ubuntu18.04 as follow :* $./config no-shared *and then:* $make $make install *after that, I write a test.c like this:* #include #include #include #include #include #include #include #include #include #include #include int generate_key(int bits, int count) { int ret = 0; RSA *r = NULL; BIGNUM *bne = NULL; unsigned long e = RSA_F4; fprintf(stdout, "id;n;e;p;q;d;t\n"); for (int i = 0; i < count; i++) { bne = BN_new(); ret = BN_set_word(bne,e); r = RSA_new(); ret = RSA_generate_key_ex(r, bits, bne, NULL); } return (ret == 1); } // added main function int main (){ printf("Hello\n"); return 0; } *and static compile it as follow:* $gcc -static -o test test.c -lssl -lcrypto -ldl -pthread x86_64-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup': dso_dlfcn.c:(.text+0x11): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking libcrypto.a(b_addr.o): In function `BIO_lookup_ex': b_addr.c:(.text+0xcea): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking x86_64-linux-gnu/libcrypto.a(b_sock.o): In function `BIO_gethostbyname': b_sock.c:(.text+0x71): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking *when i exec the test:* $./test [1] 36025 segmentation fault (core dumped) ./test *Use gdb for debug:* gdb-peda$ bt #0 0x0000000000000000 in ?? () #1 0x00000000005a14e5 in __register_frame_info_bases.part.6 () #2 0x000000000040168d in frame_dummy () #3 0x0000000000000001 in ?? () #4 0x00000000005a275c in __libc_csu_init () #5 0x00000000005a1f27 in __libc_start_main () #6 0x00000000004015aa in _start () *So, how did i use openssl for static link?* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian.sinclair at emetrotel.com Tue Sep 24 13:11:58 2019 From: ian.sinclair at emetrotel.com (Ian Sinclair) Date: Tue, 24 Sep 2019 13:11:58 +0000 Subject: Crash in OpenSSL v1.0.1 from dtls1_do_write OPENSSL_assert(len == (unsigned int)ret); Message-ID: I'm working with Asterisk PBX code which uses openSSL v1.0.2 (from Centos6). On one site we're getting a crash from dtls1_do_write and as far as I can tell it's from the assertion coded: /* bad if this assert fails, only part of the handshake * message got sent. but why would this happen? */ OPENSSL_assert(len == (unsigned int)ret); My question is the same as some previous author - why would this happen? Is there any meaningful way I can debug this? Some flag I can set that will show the DTLS packets to try to find a cause? Some way to get rid of the assertion so that the failure doesn't take down the whole system, because currently the assertion causes a reboot? It's happening on an end customer site so building a debug load isn't particularly viable, but if that's the only option tell me how. Is this a known problem that is only fixed as a non-security fix in a later release? We are current for the release, I believe, with v1.0.1e 58.el6_10. If the solution is only in later releases how compatible are those with Centos 6? I really don't want to have to go to another stream. I'm completely new to Asterisk, openSSL, core files, and pretty much everything else, so please be clear and complete in suggestions. Thanks, Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: From shivakumar2696 at gmail.com Wed Sep 25 11:18:31 2019 From: shivakumar2696 at gmail.com (shiva kumar) Date: Wed, 25 Sep 2019 16:48:31 +0530 Subject: Error while running shlibload. test case Message-ID: Hi, I'm getting error while running test case "90-test_shlibload.t" in openssl 1.1.1c make test. ../test/recipes/90-test_shlibload.t (Wstat: 1024 Tests: 10 Failed: 4) Failed tests: 2, 4, 6, 8 in file test/recipes/90-test_shlibload.t *ok(check_atexit($fh));* when i checked it is the above function call, which is throwing error. can anyone please tell me why is this happening? Regards Shivakumar -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Edwards at microfocus.com Wed Sep 25 11:22:26 2019 From: Simon.Edwards at microfocus.com (Simon Edwards) Date: Wed, 25 Sep 2019 11:22:26 +0000 Subject: Working inside X509_STORE_CTX using verification callbacks Message-ID: Hello Everyone. I am migrating code written to the old 1.0 (actually probably more like 0.9.?) X509_STORE API which has a replacement for the check_issuer callback function. Unless I am missing something the 1.1.1c SDK's public API is missing some accessor functions that are required for a like-for-like update to 1.1.1c. void X509_STORE_CTX_set0_current_issuer(X509_STORE_CTX *ctx, X509 *cert){ ctx->current_issuer = cert; } void X509_STORE_CTX_set0_error(X509_STORE_CTX *ctx, int error) { ctx->error = error; } I suspect I will need to build this as an internal OpenSSL source module in order to allow access inside the STORE structure. Or, have I missed a replacement API somewhere? The reason for using our own callback function is to allow for the situation where a trustpoint collection may contain multiple certificates with the same DN but different keys. The second (or later) of these may be the signer of the certificate being verified. The OpenSSL version would stop when it encountered the first certificate with an incorrect key. If OpenSSL now supports this situation we could remove the need to set our own callback. Simon Edwards Principal Software Engineer Micro Focus simon.edwards at microfocus.com The Lawn, 22-30 Old Bath Road Newbury, Berkshire, UK Shoretel 44224 Direct: +44 1635 565487 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Sep 25 12:31:13 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 25 Sep 2019 13:31:13 +0100 Subject: Working inside X509_STORE_CTX using verification callbacks In-Reply-To: References: Message-ID: <98e2807b-efbe-c379-63b5-106617f37854@openssl.org> On 25/09/2019 12:22, Simon Edwards wrote: > ??? void X509_STORE_CTX_set0_error(X509_STORE_CTX *ctx, int error) { > > ?? ????ctx->error = error; > > ?? } This one already exists: void X509_STORE_CTX_set_error(X509_STORE_CTX *ctx, int err) { ctx->error = err; } Other missing accessors could be added (and even backported to stable releases) if there is a strong enough justification for wanting them. Matt From matt at openssl.org Wed Sep 25 12:34:59 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 25 Sep 2019 13:34:59 +0100 Subject: Error while running shlibload. test case In-Reply-To: References: Message-ID: <5f753605-eefe-7196-1356-9c8efbe8e3ea@openssl.org> On 25/09/2019 12:18, shiva kumar wrote: > Hi, > I'm getting error while running?test case? "90-test_shlibload.t" in openssl > 1.1.1c make test. > > ../test/recipes/90-test_shlibload.t (Wstat: 1024 Tests: 10 Failed: 4) > ? Failed tests: ?2, 4, 6, 8 > > ?in file? test/recipes/90-test_shlibload.t? ? > *ok(check_atexit($fh));*?? > > when i checked it is the above function call, which is throwing error. > can anyone please tell me why is this happening? When OpenSSL is unloaded it is supposed to do some cleanup via an "atexit" handler. This test checks that the handler was called and therefore that the cleanup occurred. For some reason it didn't for you. What platform are you running this on and how did you build OpenSSL? Matt From matt at openssl.org Wed Sep 25 13:49:06 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 25 Sep 2019 14:49:06 +0100 Subject: Crash in OpenSSL v1.0.1 from dtls1_do_write OPENSSL_assert(len == (unsigned int)ret); In-Reply-To: References: Message-ID: <3a41866e-07d0-d78d-e9b4-10dc5f63fdfd@openssl.org> On 24/09/2019 14:11, Ian Sinclair wrote: > I'm working with Asterisk PBX code which uses openSSL v1.0.2 (from Centos6). On > one site we're getting a crash from dtls1_do_write and as far as I can tell it's > from the assertion coded: > > ? /* bad if this assert fails, only part of the handshake > ? ?* message got sent. ?but why would this happen? */ > ? OPENSSL_assert(len == (unsigned int)ret); > > My question is the same as some previous author - why would this happen? I've taken a look at the code in this area to try and figure out a reason. I note that the code before this looks like this: ret = dtls1_write_bytes(s, type, &s->init_buf->data[s->init_off], len); if (ret < 0) { ....omitted... } else { /* * bad if this assert fails, only part of the handshake message * got sent. but why would this happen? */ OPENSSL_assert(len == (unsigned int)ret); Most significantly I notice that this doesn't seem to handle the ret == 0 case - which is normally used to indicate an error. So looking at dtls1_write_bytes we should check whether there are any cases where it could return 0. Well that function doesn't actually do very much except call do_dtls1_write() and return the result of that. There are a few possible points where that function could return a value: 1) Returns the result of ssl3_write_pending() 2) Returns the result of ssl_dispatch_alert(). Following the logic of that we find that it ends up returning the result of a recursive do_dtls1_write() call - so we can ignore this one. 3) If len == 0 and !create_empty_fragment then we return 0. If that is the case then len == 0 and ret == 0 so the assertion would not be hit, so we can ignore this. 4) if create_empty_fragment is true we return wr->length. But there are no calls of do_dtls1_write where create_empty_fragment is true anywhere in the code. This is actually dead code (we should remove this). We can ignore this. 5) On error we return -1, which we can ignore. So it seems do_dtls1_write() will only return 0 if ssl3_write_pending() does. Looking at that function there are 3 possible points where it can return: 1) On error it returns -1, so we can ignore that. 2) In some circumstances it can return s->wpend_ret. wpend_return is set in do_dtls1_write to the value of len, so the only way it could be 0 is if len is, which would not cause the assertion to fail so we can ignore this. 3) In other circumstances it returns the result of a BIO_write() call So the only way I can see for a 0 return to come back is if BIO_write() returns that. Looking at the implementation of BIO_write() it will return 0 if: - the BIO is NULL. But there is a check for this in ssl3_write_pending() so we know this will never be the case. - If a BIO callback has been set (via BIO_set_callback()) then it will return the result from that - Otherwise the return value is the result of a write call from the underlying BIO implementation. In DTLS the underlying BIO implementation is usually a BIO_s_datagram(). That write function will return the value from a system call to send or sendto. The man pages indicate this returns -1 on error, or otherwise the number of bytes sent - so I don't see how we could ever get 0 here. So, the summary of all of that is, I think we could get a situation where the assertion is triggered if: 1) You are using BIO_set_callback() and the callback you set returns 0 2) You are using some source/sink BIO other than BIO_s_datagram() and it sometimes returns 0 from its write call. 3) You are using a filter BIO and that returns 0 during a write call Other possibilities that spring to mind are if you are using a custom BIO that doesn't behave well and returns a positive value from its write call that is not equal to the number of bytes it was asked to write. > > Is there any meaningful way I can debug this? Some flag I can set that will show > the DTLS packets to try to find a cause? Some way to get rid of the assertion so > that the failure doesn't take down the whole system, because currently the > assertion causes a reboot? In later releases I notice that this "hard" assertion has been converted to a soft assertion - i.e. it only crashes in a debug build. Otherwise it just returns -1 to indicate an error. So the equivalent of changing the code to look like this in a production build: /* * bad if this assert fails, only part of the handshake message * got sent. but why would this happen? */ if (len != (unsigned int)ret) return -1; > It's happening on an end customer site so building a > debug load isn't particularly viable, but if that's the only option tell me how. > > Is this a known problem that is only fixed as a non-security fix in a later > release? It's not a know problem as far as I can remember. But on the other hand there have been a lot of DTLS bug fixes that have gone in between 1.0.2 and 1.1.1. Note that 1.0.2 is approaching EOL (at the end of this year), so is only receiving security fixes. Since any fix we would apply doesn't sound like a security fix it wouldn't get backported to 1.0.2. > We are current for the release, I believe, with v1.0.1e 58.el6_10. I'm slightly confused here you're talking about 1.0.1e but above you said 1.02 above. Matt From markhack at markhack.com Wed Sep 25 14:26:05 2019 From: markhack at markhack.com (Mark Hack) Date: Wed, 25 Sep 2019 09:26:05 -0500 Subject: TLS does not invoke hardware acceleration except on Intel/AMD platform Message-ID: ssl_algs.c is missing the required call to OPENSSL_cpuid_setup() which means that all the platforms which rely on the CPU ID to be set (everything except Intel/AMD) never use any of the EVP calls and do not hardware accelerate TLS. Yes, the performance tests work but these do not use libssl. Patching ssl_algs.c corrects this and the performance improvement is immediatly noticable. This is the patch applied and tested on PPC. int SSL_library_init(void) { OPENSSL_cpuid_init_setup(); /* Identify the HW platform */ ... Regards Mark Hack From matt at openssl.org Wed Sep 25 15:26:27 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 25 Sep 2019 16:26:27 +0100 Subject: TLS does not invoke hardware acceleration except on Intel/AMD platform In-Reply-To: References: Message-ID: <13030c7a-9b12-602d-8829-b355a4b13807@openssl.org> On 25/09/2019 15:26, Mark Hack wrote: > ssl_algs.c is missing the required call to OPENSSL_cpuid_setup() which > means that all the platforms which rely on the CPU ID to be set > (everything except Intel/AMD) never use any of the EVP calls and do not > hardware accelerate TLS. Yes, the performance tests work but these do > not use libssl. > > Patching ssl_algs.c corrects this and the performance improvement is > immediatly noticable. This is the patch applied and tested on PPC. > > int SSL_library_init(void) > { > OPENSSL_cpuid_init_setup(); /* Identify the HW platform */ > > ... Which version of OpenSSL do you see this in? In 1.1.1 at least I see the call to OPENSSL_cpuid_setup() in the default initialisation code: https://github.com/openssl/openssl/blob/19bd1fa1ef17ff0ac071402cb6b002f1c29e37b9/crypto/init.c#L45-L70 Matt From Simon.Edwards at microfocus.com Wed Sep 25 16:58:50 2019 From: Simon.Edwards at microfocus.com (Simon Edwards) Date: Wed, 25 Sep 2019 16:58:50 +0000 Subject: Working inside X509_STORE_CTX using verification callbacks In-Reply-To: References: Message-ID: Okay. Thanks Matt, I didn't see that one in x509_vfy.c, I must look harder. I will modify our own copy of OpenSSL1.1.1c to provide the missing functions and open a PR on the master. Simon Edwards On 25/09/2019 12:31, Matt Caswell wrote: On 25/09/2019 12:22, Simon Edwards wrote: > void X509_STORE_CTX_set0_error(X509_STORE_CTX *ctx, int error) { > > ctx->error = error; > > } This one already exists: void X509_STORE_CTX_set_error(X509_STORE_CTX *ctx, int err) { ctx->error = err; } Other missing accessors could be added (and even backported to stable releases) if there is a strong enough justification for wanting them. Matt From: Simon Edwards Sent: 25 September 2019 12:22 To: openssl-users at openssl.org Subject: Working inside X509_STORE_CTX using verification callbacks Hello Everyone. I am migrating code written to the old 1.0 (actually probably more like 0.9.?) X509_STORE API which has a replacement for the check_issuer callback function. Unless I am missing something the 1.1.1c SDK's public API is missing some accessor functions that are required for a like-for-like update to 1.1.1c. void X509_STORE_CTX_set0_current_issuer(X509_STORE_CTX *ctx, X509 *cert){ ctx->current_issuer = cert; } void X509_STORE_CTX_set0_error(X509_STORE_CTX *ctx, int error) { ctx->error = error; } I suspect I will need to build this as an internal OpenSSL source module in order to allow access inside the STORE structure. Or, have I missed a replacement API somewhere? The reason for using our own callback function is to allow for the situation where a trustpoint collection may contain multiple certificates with the same DN but different keys. The second (or later) of these may be the signer of the certificate being verified. The OpenSSL version would stop when it encountered the first certificate with an incorrect key. If OpenSSL now supports this situation we could remove the need to set our own callback. Simon Edwards Principal Software Engineer Micro Focus simon.edwards at microfocus.com The Lawn, 22-30 Old Bath Road Newbury, Berkshire, UK Shoretel 44224 Direct: +44 1635 565487 -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Sep 25 17:16:50 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 25 Sep 2019 13:16:50 -0400 Subject: Working inside X509_STORE_CTX using verification callbacks In-Reply-To: References: Message-ID: <20190925171650.GQ21772@straasha.imrryr.org> On Wed, Sep 25, 2019 at 11:22:26AM +0000, Simon Edwards wrote: > void X509_STORE_CTX_set0_current_issuer(X509_STORE_CTX *ctx, X509 *cert) > { > ctx->current_issuer = cert; > } Can you provide a motivating use-case for this accessor? In verification callbacks this lets you peek not only at the current certificate, but also its issuer, but setting this has no useful side-effects. I've not looked at the CRL check code closely enough to know whether there's a use-case there, but at first glance it looks unlikely. -- Viktor. From ian.sinclair at emetrotel.com Wed Sep 25 17:41:48 2019 From: ian.sinclair at emetrotel.com (Ian Sinclair) Date: Wed, 25 Sep 2019 17:41:48 +0000 Subject: Crash in OpenSSL v1.0.1 from dtls1_do_write OPENSSL_assert(len == (unsigned int)ret); In-Reply-To: <3a41866e-07d0-d78d-e9b4-10dc5f63fdfd@openssl.org> References: , <3a41866e-07d0-d78d-e9b4-10dc5f63fdfd@openssl.org> Message-ID: Thanks for the detailed investigation. I don't know if we have a BIO callback or modified any BIO code. I'll have to dig into our version of Asterisk to see if I can tell. The version confusion is mine. We really are running 1.0.1e 58 from Centos6. I got crossed up because when I checked the documentation it only goes back to 1.0.2, so that got into my head. If we have to rebuild the code, even just to debug the external cause (I expect there is something funny being fed to openSSL) is it going to be compatible for me to use the 1.0.2 source code or are there a bunch of related packages that I would need to upgrade in parallel? Thanks. ________________________________ From: Matt Caswell Sent: September 25, 2019 9:49 AM To: Ian Sinclair ; openssl-users at openssl.org Subject: Re: Crash in OpenSSL v1.0.1 from dtls1_do_write OPENSSL_assert(len == (unsigned int)ret); On 24/09/2019 14:11, Ian Sinclair wrote: > I'm working with Asterisk PBX code which uses openSSL v1.0.2 (from Centos6). On > one site we're getting a crash from dtls1_do_write and as far as I can tell it's > from the assertion coded: > > /* bad if this assert fails, only part of the handshake > * message got sent. but why would this happen? */ > OPENSSL_assert(len == (unsigned int)ret); > > My question is the same as some previous author - why would this happen? I've taken a look at the code in this area to try and figure out a reason. I note that the code before this looks like this: ret = dtls1_write_bytes(s, type, &s->init_buf->data[s->init_off], len); if (ret < 0) { ....omitted... } else { /* * bad if this assert fails, only part of the handshake message * got sent. but why would this happen? */ OPENSSL_assert(len == (unsigned int)ret); Most significantly I notice that this doesn't seem to handle the ret == 0 case - which is normally used to indicate an error. So looking at dtls1_write_bytes we should check whether there are any cases where it could return 0. Well that function doesn't actually do very much except call do_dtls1_write() and return the result of that. There are a few possible points where that function could return a value: 1) Returns the result of ssl3_write_pending() 2) Returns the result of ssl_dispatch_alert(). Following the logic of that we find that it ends up returning the result of a recursive do_dtls1_write() call - so we can ignore this one. 3) If len == 0 and !create_empty_fragment then we return 0. If that is the case then len == 0 and ret == 0 so the assertion would not be hit, so we can ignore this. 4) if create_empty_fragment is true we return wr->length. But there are no calls of do_dtls1_write where create_empty_fragment is true anywhere in the code. This is actually dead code (we should remove this). We can ignore this. 5) On error we return -1, which we can ignore. So it seems do_dtls1_write() will only return 0 if ssl3_write_pending() does. Looking at that function there are 3 possible points where it can return: 1) On error it returns -1, so we can ignore that. 2) In some circumstances it can return s->wpend_ret. wpend_return is set in do_dtls1_write to the value of len, so the only way it could be 0 is if len is, which would not cause the assertion to fail so we can ignore this. 3) In other circumstances it returns the result of a BIO_write() call So the only way I can see for a 0 return to come back is if BIO_write() returns that. Looking at the implementation of BIO_write() it will return 0 if: - the BIO is NULL. But there is a check for this in ssl3_write_pending() so we know this will never be the case. - If a BIO callback has been set (via BIO_set_callback()) then it will return the result from that - Otherwise the return value is the result of a write call from the underlying BIO implementation. In DTLS the underlying BIO implementation is usually a BIO_s_datagram(). That write function will return the value from a system call to send or sendto. The man pages indicate this returns -1 on error, or otherwise the number of bytes sent - so I don't see how we could ever get 0 here. So, the summary of all of that is, I think we could get a situation where the assertion is triggered if: 1) You are using BIO_set_callback() and the callback you set returns 0 2) You are using some source/sink BIO other than BIO_s_datagram() and it sometimes returns 0 from its write call. 3) You are using a filter BIO and that returns 0 during a write call Other possibilities that spring to mind are if you are using a custom BIO that doesn't behave well and returns a positive value from its write call that is not equal to the number of bytes it was asked to write. > > Is there any meaningful way I can debug this? Some flag I can set that will show > the DTLS packets to try to find a cause? Some way to get rid of the assertion so > that the failure doesn't take down the whole system, because currently the > assertion causes a reboot? In later releases I notice that this "hard" assertion has been converted to a soft assertion - i.e. it only crashes in a debug build. Otherwise it just returns -1 to indicate an error. So the equivalent of changing the code to look like this in a production build: /* * bad if this assert fails, only part of the handshake message * got sent. but why would this happen? */ if (len != (unsigned int)ret) return -1; > It's happening on an end customer site so building a > debug load isn't particularly viable, but if that's the only option tell me how. > > Is this a known problem that is only fixed as a non-security fix in a later > release? It's not a know problem as far as I can remember. But on the other hand there have been a lot of DTLS bug fixes that have gone in between 1.0.2 and 1.1.1. Note that 1.0.2 is approaching EOL (at the end of this year), so is only receiving security fixes. Since any fix we would apply doesn't sound like a security fix it wouldn't get backported to 1.0.2. > We are current for the release, I believe, with v1.0.1e 58.el6_10. I'm slightly confused here you're talking about 1.0.1e but above you said 1.02 above. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From markhack at markhack.com Wed Sep 25 17:02:19 2019 From: markhack at markhack.com (Mark Hack) Date: Wed, 25 Sep 2019 12:02:19 -0500 Subject: TLS does not invoke hardware acceleration except on Intel/AMD platform In-Reply-To: <13030c7a-9b12-602d-8829-b355a4b13807@openssl.org> References: <13030c7a-9b12-602d-8829-b355a4b13807@openssl.org> Message-ID: <50c4245098410ebf06fc36c1c9962f875d8a29a9.camel@markhack.com> This was on 1.0.2 and I just checked 1.1.1, and for libssl I still only see the call for libcrypto. I can recompile and confirm later in the day to be 100% certain. On Wed, 2019-09-25 at 16:26 +0100, Matt Caswell wrote: > > On 25/09/2019 15:26, Mark Hack wrote: > > ssl_algs.c is missing the required call to OPENSSL_cpuid_setup() > > which > > means that all the platforms which rely on the CPU ID to be set > > (everything except Intel/AMD) never use any of the EVP calls and do > > not > > hardware accelerate TLS. Yes, the performance tests work but these > > do > > not use libssl. > > > > Patching ssl_algs.c corrects this and the performance improvement > > is > > immediatly noticable. This is the patch applied and tested on PPC. > > > > int SSL_library_init(void) > > { > > OPENSSL_cpuid_init_setup(); /* Identify the HW platform */ > > > > ... > > Which version of OpenSSL do you see this in? In 1.1.1 at least I see > the call to > OPENSSL_cpuid_setup() in the default initialisation code: > > https://github.com/openssl/openssl/blob/19bd1fa1ef17ff0ac071402cb6b002f1c29e37b9/crypto/init.c#L45-L70 > > Matt > From Thomas.Uban at VERIFONE.com Wed Sep 25 18:32:17 2019 From: Thomas.Uban at VERIFONE.com (Thomas Uban) Date: Wed, 25 Sep 2019 18:32:17 +0000 Subject: RSAerr(PADDING CHECK) called in success path? Message-ID: <0C0B3DE9-7CA7-4D7F-A017-582DA948022C@contoso.com> I am using the openssl 3.0.0 library in an embedded environment and added a unit test for RSA based on test/rsa_mp_test.c:test_rsa_mp(). When the test is run, I see: 1. crypto/rsa/rsa_pk1.c:RSA_padding_check_PKCS1_type_2() calls RSAerr() just before returning at the bottom of the function in what appears to be the success path. 2. crypto/rsa/rsa_ossl.c:rsa_ossl_private_decrypt() calls RSAerr() near the bottom of the function, regardless of the value of ?r? ? so also in what appears to be the success path. Both errors indicate padding problems for what are presumably good test data. If I comment out the rsa_pk1.c case and add if (r < 0) to the rsa_ossl.c case, the final comparison in the test indicates that the encrypt/decrypt resulted in the original data. What am I missing here? --tnx --tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Wed Sep 25 19:05:59 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 25 Sep 2019 19:05:59 +0000 Subject: Working inside X509_STORE_CTX using verification callbacks In-Reply-To: <20190925171650.GQ21772@straasha.imrryr.org> References: <20190925171650.GQ21772@straasha.imrryr.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of > Viktor Dukhovni > > On Wed, Sep 25, 2019 at 11:22:26AM +0000, Simon Edwards wrote: > > > void X509_STORE_CTX_set0_current_issuer(X509_STORE_CTX *ctx, X509 *cert) > > { > > ctx->current_issuer = cert; > > } > > Can you provide a motivating use-case for this accessor? In > verification callbacks this lets you peek not only at the current > certificate, but also its issuer, but setting this has no useful > side-effects. Simon may correct me on this, and it may not be useful anyway; but if memory serves, it's currently being used to set the issuer on one invocation of the callback, so that on subsequent invocations for the same certificate the callback will see the desired issuer. (The callback gets invoked once for each error that the library wants to raise regarding the certificate, doesn't it? It's been a while since I worked in this area.) So I *think* this was being used to store the application's decision about the real issuer, when there were multiple root or intermediate certificates - generally to support an RSA keypair and a DSA keypair - with the same CN, and that part of the certificate chain lacked SKID/AKID extensions so the actual issuing certificate had to be determined by key type. The application in question is actually middleware, and still has to deal with a lot of certificates that aren't v3 or otherwise don't conform to current best practice, and its trust-store configuration mechanism permits multiple trees with colliding subject DNs, so its callback contains some fairly convoluted logic to try to build a valid chain back to a trust anchor while imposing all the necessary checks to maintain security. -- Michael Wojcik Distinguished Engineer, Micro Focus From openssl-users at dukhovni.org Wed Sep 25 19:48:09 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 25 Sep 2019 15:48:09 -0400 Subject: Working inside X509_STORE_CTX using verification callbacks In-Reply-To: References: <20190925171650.GQ21772@straasha.imrryr.org> Message-ID: <20190925194809.GR21772@straasha.imrryr.org> On Wed, Sep 25, 2019 at 07:05:59PM +0000, Michael Wojcik wrote: > Simon may correct me on this, and it may not be useful anyway; but if > memory serves, it's currently being used to set the issuer on one invocation > of the callback, so that on subsequent invocations for the same certificate > the callback will see the desired issuer. The "verify callback" is called for each error during chain construction that does not cause immediate failure, and then, once the chain is built, for each layer in the chain starting with the trust-anchor reporting success or any signature or expiration issues. This final pass sets the current issuer for inspection. I would not expect the "verify callback" to construct an alternate chain, for that, with SSL one would need to instead use SSL_CTX_set_cert_verify_callback(3), which side-steps the entirety of the built-in chain construction and verification process. With that you do whatever you want, but if you then want to also run the normal verify callbacks from your own chain construction code, then perhaps you might need an accessor to set the (read-only from the perspective of those callbacks) issuer_cert. -- Viktor. From ratheesh.ksz at gmail.com Thu Sep 26 05:42:17 2019 From: ratheesh.ksz at gmail.com (ratheesh kannoth) Date: Thu, 26 Sep 2019 11:12:17 +0530 Subject: write sequence number Message-ID: Hi list, i am trying to understand write sequence number and read sequence number. Setup is simple client server with tls v1.2. when i made write sequence number to 0 (ssl/t1_enc.c --> s->s2->write_sequence to 0). i commented out all increment operate on write_sequence number. But s->s2->read_sequence number is unmodified. But there is no issue in transmission. Could any one guide me to find the sequence number used in write direction, is stored where ? -Ratheesh From matt at openssl.org Thu Sep 26 08:35:25 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 26 Sep 2019 09:35:25 +0100 Subject: TLS does not invoke hardware acceleration except on Intel/AMD platform In-Reply-To: <50c4245098410ebf06fc36c1c9962f875d8a29a9.camel@markhack.com> References: <13030c7a-9b12-602d-8829-b355a4b13807@openssl.org> <50c4245098410ebf06fc36c1c9962f875d8a29a9.camel@markhack.com> Message-ID: <656c5b10-4889-a83d-dd10-6b1ceaf63ef3@openssl.org> On 25/09/2019 18:02, Mark Hack wrote: > This was on 1.0.2 and I just checked 1.1.1, and for libssl I still only > see the call for libcrypto. I can recompile and confirm later in the > day to be 100% certain. The call to OPENSSL_cpuid_setup() in 1.1.1 is inside ossl_init_base in libcrypto. That gets called as soon as OPENSSL_init_crypto() gets called the first time. This should happen automatically as soon as you do almost anything with the libraries (either libssl or libcrypto). If it doesn't get called then nothing would work at all. Looking at the code for 1.0.2 it seems to happen in various different ways: 1) In the "ini" section on various platforms - so it should get invoked automatically when OpenSSL is loaded 2) When OpenSSL_add_all_algorithms() is called. This is part of the usual OpenSSL initialisation that applications are required to do before they use libcrypto. Strictly speaking its not required to use libssl, but I think many applications do this anyway. 3) On Windows as part of the DllMain DLL_PROCESS_ATTACH message. This gets called automatically as soon as OpenSSL is loaded if using dynamic linking 4) As part of a call to ENGINE_load_builtin_engines(). This is called automatically if you call OPENSSL_config() So it looks like, from code examination, you could end up not calling it on some platforms. Since 1.0.2 is nearing EOL and is currently only receiving security fixes this is unlikely to get fixed. My suggested workaround would be to call OpenSSL_add_all_algorithms() in 1.0.2 based applications even if you're only planning to use libssl. Matt > > > > On Wed, 2019-09-25 at 16:26 +0100, Matt Caswell wrote: >> >> On 25/09/2019 15:26, Mark Hack wrote: >>> ssl_algs.c is missing the required call to OPENSSL_cpuid_setup() >>> which >>> means that all the platforms which rely on the CPU ID to be set >>> (everything except Intel/AMD) never use any of the EVP calls and do >>> not >>> hardware accelerate TLS. Yes, the performance tests work but these >>> do >>> not use libssl. >>> >>> Patching ssl_algs.c corrects this and the performance improvement >>> is >>> immediatly noticable. This is the patch applied and tested on PPC. >>> >>> int SSL_library_init(void) >>> { >>> OPENSSL_cpuid_init_setup(); /* Identify the HW platform */ >>> >>> ... >> >> Which version of OpenSSL do you see this in? In 1.1.1 at least I see >> the call to >> OPENSSL_cpuid_setup() in the default initialisation code: >> >> > https://github.com/openssl/openssl/blob/19bd1fa1ef17ff0ac071402cb6b002f1c29e37b9/crypto/init.c#L45-L70 >> >> Matt >> > From matt at openssl.org Thu Sep 26 08:49:18 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 26 Sep 2019 09:49:18 +0100 Subject: Crash in OpenSSL v1.0.1 from dtls1_do_write OPENSSL_assert(len == (unsigned int)ret); In-Reply-To: References: <3a41866e-07d0-d78d-e9b4-10dc5f63fdfd@openssl.org> Message-ID: On 25/09/2019 18:41, Ian Sinclair wrote: > Thanks for the detailed investigation. I don't know if we have a BIO callback or > modified any BIO code. I'll have to dig into our version of Asterisk to see if I > can tell. > > The version confusion is mine. We really are running 1.0.1e 58 from Centos6. I > got crossed up because when I checked the documentation it only goes back to > 1.0.2, so that got into my head. > > If we have to rebuild the code, even just to debug the external cause (I expect > there is something funny being fed to openSSL) is it going to be compatible for > me to use the 1.0.2 source code or are there a bunch of related packages that I > would need to upgrade in parallel? >From an OpenSSL perspective 1.0.2 should be a drop in replacement for 1.0.1. However if you are using the system OpenSSL package, then upgrading that could have other impacts - but that's not something I can really advise on. Matt > > Thanks. > -------------------------------------------------------------------------------- > *From:* Matt Caswell > *Sent:* September 25, 2019 9:49 AM > *To:* Ian Sinclair ; openssl-users at openssl.org > > *Subject:* Re: Crash in OpenSSL v1.0.1 from dtls1_do_write OPENSSL_assert(len == > (unsigned int)ret); > ? > > > On 24/09/2019 14:11, Ian Sinclair wrote: >> I'm working with Asterisk PBX code which uses openSSL v1.0.2 (from Centos6). On >> one site we're getting a crash from dtls1_do_write and as far as I can tell it's >> from the assertion coded: >> >> ? /* bad if this assert fails, only part of the handshake >> ? ?* message got sent. ?but why would this happen? */ >> ? OPENSSL_assert(len == (unsigned int)ret); >> >> My question is the same as some previous author - why would this happen? > > I've taken a look at the code in this area to try and figure out a reason. > > I note that the code before this looks like this: > > ??????? ret = dtls1_write_bytes(s, type, &s->init_buf->data[s->init_off], > ??????????????????????????????? len); > ??????? if (ret < 0) { > ??????????????? ....omitted... > ??????? } else { > > ??????????? /* > ???????????? * bad if this assert fails, only part of the handshake message > ???????????? * got sent.? but why would this happen? > ???????????? */ > ??????????? OPENSSL_assert(len == (unsigned int)ret); > > Most significantly I notice that this doesn't seem to handle the ret == 0 case - > which is normally used to indicate an error. So looking at dtls1_write_bytes we > should check whether there are any cases where it could return 0. Well that > function doesn't actually do very much except call do_dtls1_write() and return > the result of that. > > There are a few possible points where that function could return a value: > > 1) Returns the result of ssl3_write_pending() > 2) Returns the result of ssl_dispatch_alert(). Following the logic of that we > find that it ends up returning the result of a recursive do_dtls1_write() call - > so we can ignore this one. > 3) If len == 0 and !create_empty_fragment then we return 0. If that is the case > then len == 0 and ret == 0 so the assertion would not be hit, so we can ignore this. > 4) if create_empty_fragment is true we return wr->length. But there are no calls > of do_dtls1_write where create_empty_fragment is true anywhere in the code. This > is actually dead code (we should remove this). We can ignore this. > 5) On error we return -1, which we can ignore. > > So it seems do_dtls1_write() will only return 0 if ssl3_write_pending() does. > > Looking at that function there are 3 possible points where it can return: > > 1) On error it returns -1, so we can ignore that. > 2) In some circumstances it can return s->wpend_ret. wpend_return is set in > do_dtls1_write to the value of len, so the only way it could be 0 is if len is, > which would not cause the assertion to fail so we can ignore this. > 3) In other circumstances it returns the result of a BIO_write() call > > So the only way I can see for a 0 return to come back is if BIO_write() returns > that. Looking at the implementation of BIO_write() it will return 0 if: > > - the BIO is NULL. But there is a check for this in ssl3_write_pending() so we > know this will never be the case. > - If a BIO callback has been set (via BIO_set_callback()) then it will return > the result from that > - Otherwise the return value is the result of a write call from the underlying > BIO implementation. > > In DTLS the underlying BIO implementation is usually a BIO_s_datagram(). That > write function will return the value from a system call to send or sendto. The > man pages indicate this returns -1 on error, or otherwise the number of bytes > sent - so I don't see how we could ever get 0 here. > > So, the summary of all of that is, I think we could get a situation where the > assertion is triggered if: > > 1) You are using BIO_set_callback() and the callback you set returns 0 > 2) You are using some source/sink BIO other than BIO_s_datagram() and it > sometimes returns 0 from its write call. > 3) You are using a filter BIO and that returns 0 during a write call > > Other possibilities that spring to mind are if you are using a custom BIO that > doesn't behave well and returns a positive value from its write call that is not > equal to the number of bytes it was asked to write. > >> >> Is there any meaningful way I can debug this? Some flag I can set that will show >> the DTLS packets to try to find a cause? Some way to get rid of the assertion so >> that the failure doesn't take down the whole system, because currently the >> assertion causes a reboot? > > In later releases I notice that this "hard" assertion has been converted to a > soft assertion - i.e. it only crashes in a debug build. Otherwise it just > returns -1 to indicate an error. So the equivalent of changing the code to look > like this in a production build: > > ??????????? /* > ???????????? * bad if this assert fails, only part of the handshake message > ???????????? * got sent.? but why would this happen? > ???????????? */ > ??????????? if (len != (unsigned int)ret) > ??????????????? return -1; > > >> It's happening on an end customer site so building a >> debug load isn't particularly viable, but if that's the only option tell me how. >> >> Is this a known problem that is only fixed as a non-security fix in a later >> release? > > It's not a know problem as far as I can remember. But on the other hand there > have been a lot of DTLS bug fixes that have gone in between 1.0.2 and 1.1.1. > > Note that 1.0.2 is approaching EOL (at the end of this year), so is only > receiving security fixes. Since any fix we would apply doesn't sound like a > security fix it wouldn't get backported to 1.0.2. > >> We are current for the release, I believe, with v1.0.1e 58.el6_10. > > I'm slightly confused here you're talking about 1.0.1e but above you said 1.02 > above. > > Matt From matt at openssl.org Thu Sep 26 09:03:30 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 26 Sep 2019 10:03:30 +0100 Subject: RSAerr(PADDING CHECK) called in success path? In-Reply-To: <0C0B3DE9-7CA7-4D7F-A017-582DA948022C@contoso.com> References: <0C0B3DE9-7CA7-4D7F-A017-582DA948022C@contoso.com> Message-ID: <722b9a92-1602-8575-bb3e-3362ef2c5cec@openssl.org> On 25/09/2019 19:32, Thomas Uban via openssl-users wrote: > I am using the openssl 3.0.0 library in an embedded environment and added a unit > test for RSA based on test/rsa_mp_test.c:test_rsa_mp(). > > When the test is run, I see: > > 1.??????crypto/rsa/rsa_pk1.c:RSA_padding_check_PKCS1_type_2() calls RSAerr() > just before returning at the bottom of the function in what appears to be the > success path. > > 2.??????crypto/rsa/rsa_ossl.c:rsa_ossl_private_decrypt() calls RSAerr() near the > bottom of the function, regardless of the value of ?r? ? so also in what appears > to be the success path. These are constant time tricks. The functions must run in the same amount of time regardless of any errors that may or may not occur. Since the act of adding an error to the error queue can itself introduce a timing difference we add the error regardless of success or failure. We then remove it again if we were actually successful (which is easier to do in constant time) in the next line using err_clear_last_constant_time(). Matt > > ? > > Both errors indicate padding problems for what are presumably good test data. If > I comment out the rsa_pk1.c case and add if (r < 0) to the rsa_ossl.c case, the > final comparison in the test indicates that the encrypt/decrypt resulted in the > original data. > > ? > > What am I missing here? > > ? > > --tnx > > --tom > > ? > > ? > > ? > From matt at openssl.org Thu Sep 26 09:19:26 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 26 Sep 2019 10:19:26 +0100 Subject: write sequence number In-Reply-To: References: Message-ID: <3c4348c1-47a2-9f59-b352-c765d2eb8033@openssl.org> On 26/09/2019 06:42, ratheesh kannoth wrote: > Hi list, > > i am trying to understand write sequence number and read sequence > number. Setup is simple client server with tls v1.2. > > when i made write sequence number to 0 (ssl/t1_enc.c --> > s->s2->write_sequence to 0). i commented out all increment operate on > write_sequence number. But s->s2->read_sequence number is unmodified. I assume you are using OpenSSL 1.0.2? s->s2 has nothing to do with TLSv1.2. That's for SSLv2 and has been removed from later versions. In 1.0.2 you need to be looking at s->s3->write_sequence and s->s3->write_sequence. It's changed location in later releases. Matt > > But there is no issue in transmission. Could any one guide me to find > the sequence number used in write direction, is stored where ? > > > -Ratheesh > From ratheesh.ksz at gmail.com Thu Sep 26 09:26:13 2019 From: ratheesh.ksz at gmail.com (ratheesh kannoth) Date: Thu, 26 Sep 2019 14:56:13 +0530 Subject: write sequence number In-Reply-To: <3c4348c1-47a2-9f59-b352-c765d2eb8033@openssl.org> References: <3c4348c1-47a2-9f59-b352-c765d2eb8033@openssl.org> Message-ID: > I assume you are using OpenSSL 1.0.2? > > s->s2 has nothing to do with TLSv1.2. That's for SSLv2 and has been removed from > later versions. In 1.0.2 you need to be looking at s->s3->write_sequence and > s->s3->write_sequence. It's changed location in later releases. > > Matt > Sorry for confusion. Openssl version = 1_0_1r TLS protocol = Tls 1.2 i modified s->s3->write_sequence only. when i composed this email, i added wrong text. -Ratheesh From matt at openssl.org Thu Sep 26 10:55:56 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 26 Sep 2019 11:55:56 +0100 Subject: write sequence number In-Reply-To: References: <3c4348c1-47a2-9f59-b352-c765d2eb8033@openssl.org> Message-ID: On 26/09/2019 10:26, ratheesh kannoth wrote: >> I assume you are using OpenSSL 1.0.2? >> >> s->s2 has nothing to do with TLSv1.2. That's for SSLv2 and has been removed from >> later versions. In 1.0.2 you need to be looking at s->s3->write_sequence and >> s->s3->write_sequence. It's changed location in later releases. >> >> Matt >> > > Sorry for confusion. > Openssl version = 1_0_1r This version is very old and out of support. You should upgrade. > TLS protocol = Tls 1.2 > > i modified s->s3->write_sequence only. when i composed this email, i > added wrong text. I assume you are modifying the increment code in tls1_mac. That codepath is only hit in certain circumstances: 1) You're not using AEAD based ciphersuites (i.e. GCM or CCM) 2) You're not using "stitched" ciphersuites. These are optimised implementations which do the encrypt+mac operation all in one go. For test purposes I suggest you build with no-asm to avoid these optimised versions Matt From John.Unsworth at synchronoss.com Fri Sep 27 13:48:02 2019 From: John.Unsworth at synchronoss.com (John Unsworth) Date: Fri, 27 Sep 2019 13:48:02 +0000 Subject: My client can not receive data in blocking mode In-Reply-To: <5ead1a33-87a3-4f8d-b6b4-5da52baaf9ad.llf@e-code.net> References: <5ead1a33-87a3-4f8d-b6b4-5da52baaf9ad.llf@e-code.net> Message-ID: You do not say what OS you are running on. Solaris 11 has a known problem with not reporting queued data. This was fixed by SRU-28. Regards, John Unsworth ________________________________ From: openssl-users on behalf of ??? Sent: Monday, September 23, 2019 4:55 am To: openssl-users Subject: My client can not receive data in blocking mode Hello I'm using openssl as client in blocking mode , i have a problem . Sometimes my program can't receive data , and acctually server has been sent the data to me. I can only receive the data by sending another request . Then the data i expected arrived with a new data sent by server . ------------------------------------------------------------------------------ bool can_read() { if(SSL_pending(m_ssl)) return true; struct timeval tv = {0 , 100}; FD_ZERO(&m_rfds); FD_SET(m_socket.fd(), &m_rfds); int ret = select( m_socket.fd()+1, &m_rfds , NULL, NULL, &tv); return ret > 0 ; } //this is the main process int try_receive(char * buf , int len ) { if( !can_read()) return -1; return SSL_read(m_ssl, buf, len); } ------------------------------------------------------------------------------- Above is my code , my program get `false` from `can_read` although the server has sent response data I really appreciate your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From llf at e-code.net Fri Sep 27 15:42:07 2019 From: llf at e-code.net (llf at e-code.net) Date: Fri, 27 Sep 2019 23:42:07 +0800 Subject: My client can not receive data in blocking mode References: <5ead1a33-87a3-4f8d-b6b4-5da52baaf9ad.llf@e-code.net>, Message-ID: <201909272342066110696@e-code.net> Thank you very much for your reply . My server running on centos 7.5 . And client running on windows 10 . The data seems be cached on the server and not be sent out. Dose centos have the same problem? I'm not sure what the problem is . I would really appreciate if you have any Suggestions. Best Regards ???? John Unsworth ????? 2019-09-27 21:48 ???? ???; openssl-users ??? Re: My client can not receive data in blocking mode You do not say what OS you are running on. Solaris 11 has a known problem with not reporting queued data. This was fixed by SRU-28. Regards, John Unsworth From: openssl-users on behalf of ??? Sent: Monday, September 23, 2019 4:55 am To: openssl-users Subject: My client can not receive data in blocking mode Hello I'm using openssl as client in blocking mode , i have a problem . Sometimes my program can't receive data , and acctually server has been sent the data to me. I can only receive the data by sending another request . Then the data i expected arrived with a new data sent by server . ------------------------------------------------------------------------------ bool can_read() { if(SSL_pending(m_ssl)) return true; struct timeval tv = {0 , 100}; FD_ZERO(&m_rfds); FD_SET(m_socket.fd(), &m_rfds); int ret = select( m_socket.fd()+1, &m_rfds , NULL, NULL, &tv); return ret > 0 ; } //this is the main process int try_receive(char * buf , int len ) { if( !can_read()) return -1; return SSL_read(m_ssl, buf, len); } ------------------------------------------------------------------------------- Above is my code , my program get `false` from `can_read` although the server has sent response data I really appreciate your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.r.stephens at gmail.com Fri Sep 27 16:39:41 2019 From: bruce.r.stephens at gmail.com (Bruce Stephens) Date: Fri, 27 Sep 2019 17:39:41 +0100 Subject: X509_NAME canon_enc, canon_enclen Message-ID: I have some code accessing these fields from X509_NAME pointers, but obviously that's not allowed in 1.1. I think the code can be restructured to use X509_NAME_cmp instead. Maybe. But before I start that, is there some strong reason for not offering an accessor function? Something like X509_NAME_get0_canonenc(const X509_NAME*, const unsigned char* *canonenc, unsigned int *canon_len) From Michael.Wojcik at microfocus.com Fri Sep 27 18:50:17 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 27 Sep 2019 18:50:17 +0000 Subject: My client can not receive data in blocking mode In-Reply-To: <201909272342066110696@e-code.net> References: <5ead1a33-87a3-4f8d-b6b4-5da52baaf9ad.llf@e-code.net>, <201909272342066110696@e-code.net> Message-ID: From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of llf at e-code.net Sent: Friday, September 27, 2019 11:42 > The data seems be cached on the server and not be sent out. Is it? Have you run a network trace? Have you tried waiting longer than 100ms? If your server is sending a segment shorter than the MSS, you may be seeing Nagle / Delayed ACK interaction. If that's holding up the end of a TLS record, then select will indicate the socket is readable but a subsequent SSL_read will block until the remainder of the record has been received. A network trace, even without decryption, will give you some idea of when data is being sent, and how much. -- Michael Wojcik Distinguished Engineer, Micro Focus From nagalakshmi.j at altran.com Mon Sep 30 06:43:54 2019 From: nagalakshmi.j at altran.com (Nagalakshmi V J) Date: Mon, 30 Sep 2019 06:43:54 +0000 Subject: OpenSSL compilation errors in Windows Message-ID: Hi, I am using openssl 1.1.c from our product code. While compiling the code, I am getting the errors which can be suppressed as warnings using -fpermissive flag in Linux (gcc/g++). In windows, I am getting the same compilation errors in visual studio (2005). Would like to know the alternative of -fpermissive flag that can be used in visual studio to suppress the errors. I tried adding the flags such as '/fpermissive' , '/Ze' in module properties->C/C++->command Line->Additional options. But it did not resolve the problem. Getting the errors like below. ssl/packet_locl.h(429) : error C2440: '=' : cannot convert from 'void *' to 'unsigned char 'Conversion from 'void' to pointer to non-'void' requires an explicit cast Since it is giving error in Openssl code, we cannot make any code changes there. Has anyone faced this kind of issue? Please let me know how to resolve this issue. Thanks and regards, Nagalakshmi ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Mon Sep 30 08:40:08 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 30 Sep 2019 08:40:08 +0000 Subject: AW: OpenSSL compilation errors in Windows In-Reply-To: References: Message-ID: <8d86ada179cc4c2bb2d884d8ab03878d@Ex13.ncp.local> > Getting the errors like below. ssl/packet_locl.h(429) : error C2440: '=' : cannot convert from 'void *' to 'unsigned char 'Conversion from 'void' to pointer to non-'void' requires an explicit cast Is it possible that your error message was copied incorrectly? Line 429 is an assignment from 'void *' to 'unsigned char*', not to 'unsigned char'. Such an assignment is allowed in C (and the type is implicitly converted), but not in C++. Is it possible, that you are including this header in a module compiled with a C++ compiler? Note that this is an internal header file and not meant to be included by third party software. HTH, Matthias Von: openssl-users Im Auftrag von Nagalakshmi V J Gesendet: Montag, 30. September 2019 08:44 An: openssl-users at openssl.org Cc: Umamaheswari Nagarajan Betreff: OpenSSL compilation errors in Windows Hi, I am using openssl 1.1.c from our product code. While compiling the code, I am getting the errors which can be suppressed as warnings using -fpermissive flag in Linux (gcc/g++). In windows, I am getting the same compilation errors in visual studio (2005). Would like to know the alternative of -fpermissive flag that can be used in visual studio to suppress the errors. I tried adding the flags such as '/fpermissive' , '/Ze' in module properties->C/C++->command Line->Additional options. But it did not resolve the problem. Getting the errors like below. ssl/packet_locl.h(429) : error C2440: '=' : cannot convert from 'void *' to 'unsigned char 'Conversion from 'void' to pointer to non-'void' requires an explicit cast Since it is giving error in Openssl code, we cannot make any code changes there. Has anyone faced this kind of issue? Please let me know how to resolve this issue. Thanks and regards, Nagalakshmi ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== From nagesh.shamnur at huawei.com Mon Sep 30 10:13:38 2019 From: nagesh.shamnur at huawei.com (Nagesh shamnur) Date: Mon, 30 Sep 2019 10:13:38 +0000 Subject: Regarding using OpenSSL along with optee Message-ID: Dear OpenSSL Group, Greetings. I was checking for the support for Trusted Execution Environment (TEE) in OpenSSL. I could see that the current design is modular enough to support it. But sadly, I was unable to find the relevant code changes adapting any TEE implementation such as op-tee in the version 1.1.1d. Can someone guide me if such a code changes are available. Regards, Nagesh S -------------- next part -------------- An HTML attachment was scrubbed... URL: From abaci.mjm at gmail.com Mon Sep 30 10:34:53 2019 From: abaci.mjm at gmail.com (Michael Mueller) Date: Mon, 30 Sep 2019 06:34:53 -0400 Subject: OpenSSL compilation errors in Windows In-Reply-To: References: Message-ID: We compile using Visual Studio. We don't use 'warnings as errors' and selected a warning level that minimized warnings. The 'make test' runs cleanly. On Mon, Sep 30, 2019, 3:16 AM Nagalakshmi V J wrote: > Hi, > > I am using openssl 1.1.c from our product code. While compiling the code, > I am getting the errors which can be suppressed as warnings using > -fpermissive flag in Linux (gcc/g++). In windows, I am getting the same > compilation errors in visual studio (2005). Would like to know the > alternative of -fpermissive flag that can be used in visual studio to > suppress the errors. > > I tried adding the flags such as '/fpermissive' , '/Ze' in module > properties->C/C++->command Line->Additional options. But it did not resolve > the problem. > > *Getting the errors like below. ssl/packet_locl.h(429) : error C2440: '=' > : cannot convert from 'void *' to 'unsigned char **'Conversion from 'void**' > to pointer to non-'void' requires an explicit cast* > > > > Since it is giving error in Openssl code, we cannot make any code changes > there. Has anyone faced this kind of issue? > > Please let me know how to resolve this issue. > > > > > > > > *Thanks and regards,* > > *Nagalakshmi* > > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nagalakshmi.j at altran.com Mon Sep 30 10:56:11 2019 From: nagalakshmi.j at altran.com (Nagalakshmi V J) Date: Mon, 30 Sep 2019 10:56:11 +0000 Subject: OpenSSL compilation errors in Windows In-Reply-To: <8d86ada179cc4c2bb2d884d8ab03878d@Ex13.ncp.local> References: <8d86ada179cc4c2bb2d884d8ab03878d@Ex13.ncp.local> Message-ID: Hi Matthias, Yes that's right. The error message is ..\..\OpenSSL\openssl-1.1.1c\crypto\../ssl/packet_locl.h(429) : error C2440: '=' : cannot convert from 'void *' to 'unsigned char *' Conversion from 'void*' to pointer to non-'void' requires an explicit cast Sorry, it was missed by mistake. So how can we avoid this? In our code, We included ?ssl_locl.h? which in turn includes packet_locl.h. Any way to avoid this kind of error? Thanks and regards, Nagalakshmi -----Original Message----- From: Dr. Matthias St. Pierre Sent: Monday, September 30, 2019 2:10 PM To: Nagalakshmi V J ; openssl-users at openssl.org Cc: Umamaheswari Nagarajan Subject: AW: OpenSSL compilation errors in Windows ** This mail has been sent from an external source ** > Getting the errors like below. ssl/packet_locl.h(429) : error C2440: > '=' : cannot convert from 'void *' to 'unsigned char 'Conversion from > 'void' to pointer to non-'void' requires an explicit cast Is it possible that your error message was copied incorrectly? Line 429 is an assignment from 'void *' to 'unsigned char*', not to 'unsigned char'. Such an assignment is allowed in C (and the type is implicitly converted), but not in C++. Is it possible, that you are including this header in a module compiled with a C++ compiler? Note that this is an internal header file and not meant to be included by third party software. HTH, Matthias Dr. Matthias St. Pierre Senior Software Engineer matthias.st.pierre at ncp-e.com Phone: +49 911 9968-0 www.ncp-e.com Headquarters Germany: NCP engineering GmbH ? Dombuehler Str. 2 ? 90449 ? Nuremberg North American HQ: NCP engineering Inc. ? 678 Georgia Ave. ? Sunnyvale, CA 94085 East Coast Office: NCP engineering Inc. ? 601 Cleveland Str., Suite 501-25 ? Clearwater, FL 33755 Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich Registry Court: Lower District Court of Nuremberg Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE 133557619 This e-mail message including any attachments is for the sole use of the intended recipient(s) and may contain privileged or confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply e-mail and delete the original message and destroy all copies thereof. Von: openssl-users > Im Auftrag von Nagalakshmi V J Gesendet: Montag, 30. September 2019 08:44 An: openssl-users at openssl.org Cc: Umamaheswari Nagarajan > Betreff: OpenSSL compilation errors in Windows Hi, I am using openssl 1.1.c from our product code. While compiling the code, I am getting the errors which can be suppressed as warnings using -fpermissive flag in Linux (gcc/g++). In windows, I am getting the same compilation errors in visual studio (2005). Would like to know the alternative of -fpermissive flag that can be used in visual studio to suppress the errors. I tried adding the flags such as '/fpermissive' , '/Ze' in module properties->C/C++->command Line->Additional options. But it did not resolve the problem. Getting the errors like below. ssl/packet_locl.h(429) : error C2440: '=' : cannot convert from 'void *' to 'unsigned char 'Conversion from 'void' to pointer to non-'void' requires an explicit cast Since it is giving error in Openssl code, we cannot make any code changes there. Has anyone faced this kind of issue? Please let me know how to resolve this issue. Thanks and regards, Nagalakshmi ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Sep 30 11:02:23 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 30 Sep 2019 12:02:23 +0100 Subject: OpenSSL compilation errors in Windows In-Reply-To: References: <8d86ada179cc4c2bb2d884d8ab03878d@Ex13.ncp.local> Message-ID: On 30/09/2019 11:56, Nagalakshmi V J wrote: > In our code, We included ?ssl_locl.h? which in turn includes packet_locl.h. Any > way to avoid this kind of error? Don't include "ssl_locl.h"!!! This is an internal header file and relying on it is likely to cause problems for you. There are no stability guarantees if you use internal stuff. For example commit b5acbf9148 just renamed that file to ssl_local.h. That change will be in OpenSSL 1.1.1e - so your code will break at that point if you upgrade. Anything in your code that relies on that internal data will need to be rewritten to use the public APIs instead. Matt > > ? > > Thanks and regards, > > Nagalakshmi > > ? > > -----Original Message----- > From: Dr. Matthias St. Pierre > Sent: Monday, September 30, 2019 2:10 PM > To: Nagalakshmi V J ; openssl-users at openssl.org > Cc: Umamaheswari Nagarajan > Subject: AW: OpenSSL compilation errors in Windows > > ? > > ** This mail has been sent from an external source ** > > ? > > ? > >> Getting the errors like below. ssl/packet_locl.h(429) : error C2440: > >> '=' : cannot convert from 'void *' to 'unsigned char 'Conversion from > >> 'void' to pointer to non-'void' requires an explicit cast > > ? > > Is it possible that your error message was copied incorrectly? Line 429 is an > assignment from 'void *' to 'unsigned char*', not to 'unsigned char'. > > ? > > Such an assignment is allowed in C (and the type is implicitly converted), but > not in C++. Is it possible, that you are including this header in a module > compiled with a C++ compiler? Note that this is an internal header file and not > meant to be included by third party software. > > ? > > HTH, > > Matthias > > ? > > ? > > ? > > ? > > ? > > ? > > Dr. Matthias St. Pierre > > Senior Software Engineer > > matthias.st.pierre at ncp-e.com > > Phone: +49 911 9968-0 > > www.ncp-e.com > > ? > > Headquarters Germany: NCP engineering GmbH ? Dombuehler Str. 2 ? 90449 ? > Nuremberg North American HQ: NCP engineering Inc. ? 678 Georgia Ave. ? > Sunnyvale, CA 94085 East Coast Office: NCP engineering Inc. ? 601 Cleveland > Str., Suite 501-25 ? Clearwater, FL 33755 > > ? > > Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich > Registry Court: Lower District Court of Nuremberg Commercial register No.: HRB > 7786 Nuremberg, VAT identification No.: DE 133557619 > > ? > > This e-mail message including any attachments is for the sole use of the > intended recipient(s) and may contain privileged or confidential information. > Any unauthorized review, use, disclosure or distribution is prohibited. If you > are not the intended recipient, please immediately contact the sender by reply > e-mail and delete the original message and destroy all copies thereof. > > Von: openssl-users > Im Auftrag von Nagalakshmi V J > > Gesendet: Montag, 30. September 2019 08:44 > > An: openssl-users at openssl.org > > Cc: Umamaheswari Nagarajan > > > Betreff: OpenSSL compilation errors in Windows > > ? > > Hi, > > I am using openssl 1.1.c from our product code. While compiling the code, I am > getting the errors which can be suppressed as warnings using -fpermissive flag > in Linux (gcc/g++). In windows, I am getting the same compilation errors in > visual studio (2005). Would like to know the alternative of -fpermissive flag > that can be used in visual studio to suppress the errors. > > I tried adding the flags such as '/fpermissive' , '/Ze' in module > properties->C/C++->command Line->Additional options. But it did not resolve the > problem. > > Getting the errors like below. ssl/packet_locl.h(429) : error C2440: '=' : > cannot convert from 'void *' to 'unsigned char 'Conversion from 'void' to > pointer to non-'void' requires an explicit cast > > ? > > Since it is giving error in Openssl code, we cannot make any code changes there. > Has anyone faced this kind of issue? > > Please let me know how to resolve this issue. > > ? > > ? > > ? > > Thanks and regards, > > Nagalakshmi > > ? > > ===================================================== > > Please refer to https://northamerica.altran.com/email-disclaimer > > for important disclosures regarding this electronic communication. > > ===================================================== > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== From nagalakshmi.j at altran.com Mon Sep 30 10:54:21 2019 From: nagalakshmi.j at altran.com (Nagalakshmi V J) Date: Mon, 30 Sep 2019 10:54:21 +0000 Subject: OpenSSL compilation errors in Windows In-Reply-To: References: Message-ID: Hi Michael, OpenSSL code is compiling without any issues. When it is used from our product code and while compiling using C++ compiler, the issue is seen. We also don?t use the ?warning as errors? and warning level 3 we are using currently. Thanks and regards, Nagalakshmi From: Michael Mueller Sent: Monday, September 30, 2019 4:05 PM To: Nagalakshmi V J Cc: openssl-users at openssl.org; Umamaheswari Nagarajan Subject: Re: OpenSSL compilation errors in Windows ** This mail has been sent from an external source ** We compile using Visual Studio. We don't use 'warnings as errors' and selected a warning level that minimized warnings. The 'make test' runs cleanly. On Mon, Sep 30, 2019, 3:16 AM Nagalakshmi V J > wrote: Hi, I am using openssl 1.1.c from our product code. While compiling the code, I am getting the errors which can be suppressed as warnings using -fpermissive flag in Linux (gcc/g++). In windows, I am getting the same compilation errors in visual studio (2005). Would like to know the alternative of -fpermissive flag that can be used in visual studio to suppress the errors. I tried adding the flags such as '/fpermissive' , '/Ze' in module properties->C/C++->command Line->Additional options. But it did not resolve the problem. Getting the errors like below. ssl/packet_locl.h(429) : error C2440: '=' : cannot convert from 'void *' to 'unsigned char 'Conversion from 'void' to pointer to non-'void' requires an explicit cast Since it is giving error in Openssl code, we cannot make any code changes there. Has anyone faced this kind of issue? Please let me know how to resolve this issue. Thanks and regards, Nagalakshmi ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Sep 30 12:33:20 2019 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 30 Sep 2019 12:33:20 +0000 Subject: Regarding using OpenSSL along with optee In-Reply-To: References: Message-ID: <572A0BCA-01E0-45E9-A7EB-88BC980C095A@akamai.com> > Greetings. I was checking for the support for Trusted Execution Environment (TEE) in OpenSSL. I?m curious ? what do you think would be required? -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Mon Sep 30 12:34:08 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Mon, 30 Sep 2019 22:34:08 +1000 Subject: Regarding using OpenSSL along with optee In-Reply-To: References: Message-ID: <3BECA581-9604-4AD9-89DC-08B859E1634E@oracle.com> I?m not aware of any such work having been undertaken. OpenSSL 3.0 will definitely be sufficiently modular to support this. 1.1.1 a little less so but it might be possible. If anyone is willing to take this up, I?d suggest targeting OpenSSL 3.0. At the moment we are busy with FIPS and the 3.0 architectural changes. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 30 Sep 2019, at 8:13 pm, Nagesh shamnur wrote: > > Dear OpenSSL Group, > Greetings. I was checking for the support for Trusted Execution Environment (TEE) in OpenSSL. I could see that the current design is modular enough to support it. But sadly, I was unable to find the relevant code changes adapting any TEE implementation such as op-tee in the version 1.1.1d. Can someone guide me if such a code changes are available. > > Regards, > Nagesh S -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgh at wizmail.org Mon Sep 30 13:49:44 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Mon, 30 Sep 2019 14:49:44 +0100 Subject: full-chain ocsp stapling Message-ID: <86bfc59e-a2d8-d2a3-a81d-3abf43705853@wizmail.org> Looking at implementing the above, under TLSv1.3 and (at least initially) server-side. I'm currently using SSL_CTX_set_tlsext_status_cb() SSL_set_tlsext_status_ocsp_resp( a DER blob ) and the problem is: will this accept a (DER-wrapped, basicresp-wrapped) stack of singleresp where the stack has >1 element? If so, and that is the preferred way to load such a stapling, how can such a blob be constructed? I have separate PEM files for each ocsp resp for the certificate chain, currently. Converting to DER and pulling out the singleresp is feasible; it's building a multi-resp blob that looks hard. Alternatively, can SSL_set_tlsext_status_ocsp_resp() be called repeatedly, with distinct blobs for the stapling chain elements? The manpage does not suggest it so it seems unlikely. Alternatively^2, is there some way to get such a blob from a tool (openssl ocsp, or similar) ready built? For this purpose, I am the CA. -- Cheers, Jeremy From Matthias.St.Pierre at ncp-e.com Mon Sep 30 14:28:50 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 30 Sep 2019 14:28:50 +0000 Subject: AW: OpenSSL compilation errors in Windows In-Reply-To: References: Message-ID: > OpenSSL code is compiling without any issues. When it is used from our product code and while compiling using C++ compiler, the issue is seen. As I wrote previously, the error you posted was caused by the fact that you are compiling Ansi C (a.k.a ISO/IEC 9899:1990, a.k.a C90) source code using a C++ compiler. While C permits a cast from ?void *? to ?anytype *?, C++ doesn?t allow it without an explicit cast. Only the *public* OpenSSL headers are guaranteed to be includable by a C++ compiler (they contain the necessary ` extern ?C? ` blocks, etc.), not the internal headers. Including *internal* headers is neither supported nor possible with a C++ compiler. And as Matt Caswell already told you, there are no compatibility guarantees for those headers. Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From sfhacker at hotmail.com Mon Sep 30 15:36:27 2019 From: sfhacker at hotmail.com (Sergio NNX) Date: Mon, 30 Sep 2019 15:36:27 +0000 Subject: OpenSSL compilation errors in Windows In-Reply-To: References: , Message-ID: Ciao. I haven't had a chance to compile the exact OpenSSL version using g++ compiler as stated by the user/poster. If this user is using a modified or altered version of OpenSSL provided source code, is there support available? Don't get me wrong, I don't mind helping out but ..... I'll try to compile OpenSSL source code this evening and I'll post my findings here. Regards. Sergio. ________________________________ From: openssl-users on behalf of Dr. Matthias St. Pierre Sent: Tuesday, 1 October 2019 12:28 AM To: Nagalakshmi V J ; Michael Mueller Cc: openssl-users at openssl.org ; Umamaheswari Nagarajan Subject: AW: OpenSSL compilation errors in Windows > OpenSSL code is compiling without any issues. When it is used from our product code and while compiling using C++ compiler, the issue is seen. As I wrote previously, the error you posted was caused by the fact that you are compiling Ansi C (a.k.a ISO/IEC 9899:1990, a.k.a C90) source code using a C++ compiler. While C permits a cast from ?void *? to ?anytype *?, C++ doesn?t allow it without an explicit cast. Only the *public* OpenSSL headers are guaranteed to be includable by a C++ compiler (they contain the necessary ` extern ?C? ` blocks, etc.), not the internal headers. Including *internal* headers is neither supported nor possible with a C++ compiler. And as Matt Caswell already told you, there are no compatibility guarantees for those headers. Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Sep 30 16:02:59 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 30 Sep 2019 17:02:59 +0100 Subject: full-chain ocsp stapling In-Reply-To: <86bfc59e-a2d8-d2a3-a81d-3abf43705853@wizmail.org> References: <86bfc59e-a2d8-d2a3-a81d-3abf43705853@wizmail.org> Message-ID: <9d2cfd7b-c83d-06ba-5a46-da3fd0672697@openssl.org> On 30/09/2019 14:49, Jeremy Harris wrote: > Looking at implementing the above, under TLSv1.3 and (at least > initially) server-side. I'm currently using > > SSL_CTX_set_tlsext_status_cb() > SSL_set_tlsext_status_ocsp_resp( a DER blob ) > > and the problem is: will this accept a > (DER-wrapped, basicresp-wrapped) stack of singleresp > where the stack has >1 element? It's an OCSPResponse object (see RFC2560) - represented by the OCSP_RESPONSE type in OpenSSL. That can itself wrap a BasicOCSPResponse which can contain multiple SingleResponses. > > If so, and that is the preferred way to load such > a stapling, how can such a blob be constructed? If you want to construct it from scratch you might want to take a look at how the ocsp app does it: https://github.com/openssl/openssl/blob/84f471ecab76a16281a16c53d259bbcae358816f/apps/ocsp.c#L1146-L1287 > > I have separate PEM files for each ocsp resp for > the certificate chain, currently. Converting > to DER and pulling out the singleresp is feasible; > it's building a multi-resp blob that looks hard. > > Alternatively, can SSL_set_tlsext_status_ocsp_resp() > be called repeatedly, with distinct blobs for the > stapling chain elements? The manpage does not suggest it > so it seems unlikely. No, this isn't possible. > > Alternatively^2, is there some way to get such a blob from > a tool (openssl ocsp, or similar) ready built? For this > purpose, I am the CA. > Yes, you can do this. For example see the "respout" option in the ocsp command. >From the examples in the ocsp man page: Send a query to an OCSP responder with URL http://ocsp.myhost.com/ save the response to a file, print it out in text form, and verify the response: openssl ocsp -issuer issuer.pem -cert c1.pem -cert c2.pem \ -url http://ocsp.myhost.com/ -resp_text -respout resp.der Read in an OCSP response and print out text form: openssl ocsp -respin resp.der -text -noverify https://www.openssl.org/docs/man1.1.1/man1/openssl-ocsp.html Matt From jgh at wizmail.org Mon Sep 30 16:27:36 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Mon, 30 Sep 2019 17:27:36 +0100 Subject: full-chain ocsp stapling In-Reply-To: <9d2cfd7b-c83d-06ba-5a46-da3fd0672697@openssl.org> References: <86bfc59e-a2d8-d2a3-a81d-3abf43705853@wizmail.org> <9d2cfd7b-c83d-06ba-5a46-da3fd0672697@openssl.org> Message-ID: On 30/09/2019 17:02, Matt Caswell wrote: > openssl ocsp -issuer issuer.pem -cert c1.pem -cert c2.pem \ > -url http://ocsp.myhost.com/ -resp_text -respout resp.der Ah, I hadn't realised that -cert could be given multiple times. -- Thanks, Jeremy From upadhyay.manoj at live.com Mon Sep 30 18:28:06 2019 From: upadhyay.manoj at live.com (manoj upadhyay) Date: Mon, 30 Sep 2019 18:28:06 +0000 Subject: Issue in upgrading code related to CAPI Engine for accessing Windows certificate Store(Windows7) (upgrade from 1.0.2p to 1.1.1c) Message-ID: Hi All, I am facinmg issue while upgrading my OpenSSL version from 1.0.2p to 1.1.1c. I am facing the issue where "ENGINE_by_id("capi")" is not returning proper pointer. I want to access windows certificate store with certificate and keys. Snippet of my working code in 1.0.2p:(This is working fine) This is working fine and I am able to get the Private key. -------------------------------------- ENGINE_load_capi() ce = ENGINE_by_id("capi"); if (NULL == ce) { ENGINE_cleanup(); return E_LOAD_FAILED; } if (!ENGINE_init(ce)||!ENGINE_register_STORE(ce) ) { ENGINE_cleanup(); ce = NULL; return E_INIT_FAILED; } (void)ENGINE_ctrl_cmd(ce,"store_flags",0, NULL, NULL, 0); (void)ENGINE_ctrl_cmd(ce,"store_name" ,0, (void*)storeName, NULL, 0); privateKey = ENGINE_load_private_key(ce,"certname", 0, 0); I can see that few CAPI API is deprecated in 1.1.1c, but they can be enabled by following configuration(Based on engine.h) > "perl Configure debug-VC-WIN64A no-asm enable-capieng no-shared no-dynamic-engine --api=1.0.0" Code from 1.1.1c: ------------------- ENGINE_load_capi() ce = ENGINE_by_id("capi"); <<================Returning NULL always if (NULL == ce) { ENGINE_cleanup(); return E_LOAD_FAILED; } if (!ENGINE_init(ce)||!ENGINE_register_complete(ce) ) { ENGINE_cleanup(); ce = NULL; return E_INIT_FAILED; } (void)ENGINE_ctrl_cmd(ce,"store_flags",0, NULL, NULL, 0); (void)ENGINE_ctrl_cmd(ce,"store_name" ,0, (void*)storeName, NULL, 0); privateKey = ENGINE_load_private_key(ce,"certname", 0, 0); If I change my code to the following way, I get one pointer but when I try to load the private key I get always empty private key. > "perl Configure debug-VC-WIN64A no-asm Code: int rc = 0; ENGINE_load_builtin_engines(); ce= ENGINE_by_id("dynamic"); <<==============Engine Pointer with no valid data rc = ENGINE_ctrl_cmd_string(ce, "SO_PATH", "c://mylib//capi.dll", 0); if (! rc) return ERROR_RC; rc= ENGINE_ctrl_cmd_string(ce, "LOAD", NULL, 0); if (! rc) return ERROR_RC; rc = ENGINE_register_complete(ce); if (! rc) return ERROR_RC; rc = ERR_load_ENGINE_strings(); if (! rc) return ERROR_RC; if (NULL == ce) { ENGINE_cleanup(); return LOAD_E_FAILED; } if (!ENGINE_init(ce)) { ENGINE_cleanup(); sCapiEngine = NULL; return INIT_E_FAILED; } ENGINE_register_complete(ce); (void)ENGINE_ctrl_cmd(ce,"store_flags",0, NULL, NULL, 0); (void)ENGINE_ctrl_cmd(ce,"store_name" ,0, (void*)storeName, NULL, 0); privateKey = ENGINE_load_private_key(ce,"certname", 0, 0); <<============Always getting NULL Private key. I am not able to figure out where things are going wrong. Is there any way I can get the desired result from Capi for windows cert store? Please help. Thanks & regards, Manoj Upadhyay -------------- next part -------------- An HTML attachment was scrubbed... URL: