From rt at openssl.org Sun Nov 1 13:44:24 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 01 Nov 2015 13:44:24 +0000 Subject: [openssl-dev] [openssl.org #4113] [PATCH] Cleanup and update README In-Reply-To: <20151031121945.GA11316@kronk.local> References: <20151031121945.GA11316@kronk.local> Message-ID: done ,along with some other cleanups. on master 102 101 thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From laurenz.albe at wien.gv.at Mon Nov 2 10:16:35 2015 From: laurenz.albe at wien.gv.at (Albe Laurenz) Date: Mon, 2 Nov 2015 10:16:35 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <562D5D30.9060909@openssl.org> <2967819.dUliAttKOr@pintsize.usersys.redhat.com> Message-ID: Hubert Kario wrote: > On Sunday 25 October 2015 22:52:36 Matt Caswell via RT wrote: >> My concern though is broader than this specific case. I have given two >> *examples* of exploits that we may open ourselves up to if we attempt >> to process this application data without some fairly significant >> refactoring of the code to separate out state currently in the >> process of being negotiated from state for the current epoch. We >> could probably patch things up to work around these two specific >> examples but I worry that without the more significant refactoring >> work, we may open ourselves up to other attacks that we haven't >> thought of. > > unfortunately I have to agree. Those two examples show in rather clear > terms that openssl as it is now in stable branches, can't be easily > patched up to handle even specific situations of interleaved app data > with handshake data in renegotiated handshakes. So breaking such > connections is a safer option. > > That being said, Java behaviour is dangerous only if they expose to the > application the "in negotiation" context instead of the "currently > active" context. Not exactly easy to test. Sorry for being obtuse, but I don't see yet why these concerns should prevent a simple fix. If interleaved application data are only allowed a) before Change Cipher Spec b) during a renegotiation, i.e., when the connection is encrypted your second example and similar exploits would not work, because the application data would have to be encrypted with a cipher that is known to be secure. That leaves us with the first problem, namely that calls like SSL_get_peer_certificate() will return incorrect values when renegotiation has started but is not yet complete. I agree that the window for such a mistake will be widened somewhat if the client were allowed to send application data after renegotiation has started, but the problem already exists in the current code, right? What keeps the client from first sending the application data that cause the dangerous call by the server and immediately afterwards starting a renegotiation with a certificate for which they have no private key? So I think that that is a separate issue that should not be held against an improvement like the one this patch would provide. Maybe it can be fixed by disallowing callbacks that would return incorrect data while renegotiation is in progress. Yours, Laurenz Albe From rt at openssl.org Mon Nov 2 10:16:49 2015 From: rt at openssl.org (Albe Laurenz via RT) Date: Mon, 02 Nov 2015 10:16:49 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <562D5D30.9060909@openssl.org> <2967819.dUliAttKOr@pintsize.usersys.redhat.com> Message-ID: Hubert Kario wrote: > On Sunday 25 October 2015 22:52:36 Matt Caswell via RT wrote: >> My concern though is broader than this specific case. I have given two >> *examples* of exploits that we may open ourselves up to if we attempt >> to process this application data without some fairly significant >> refactoring of the code to separate out state currently in the >> process of being negotiated from state for the current epoch. We >> could probably patch things up to work around these two specific >> examples but I worry that without the more significant refactoring >> work, we may open ourselves up to other attacks that we haven't >> thought of. > > unfortunately I have to agree. Those two examples show in rather clear > terms that openssl as it is now in stable branches, can't be easily > patched up to handle even specific situations of interleaved app data > with handshake data in renegotiated handshakes. So breaking such > connections is a safer option. > > That being said, Java behaviour is dangerous only if they expose to the > application the "in negotiation" context instead of the "currently > active" context. Not exactly easy to test. Sorry for being obtuse, but I don't see yet why these concerns should prevent a simple fix. If interleaved application data are only allowed a) before Change Cipher Spec b) during a renegotiation, i.e., when the connection is encrypted your second example and similar exploits would not work, because the application data would have to be encrypted with a cipher that is known to be secure. That leaves us with the first problem, namely that calls like SSL_get_peer_certificate() will return incorrect values when renegotiation has started but is not yet complete. I agree that the window for such a mistake will be widened somewhat if the client were allowed to send application data after renegotiation has started, but the problem already exists in the current code, right? What keeps the client from first sending the application data that cause the dangerous call by the server and immediately afterwards starting a renegotiation with a certificate for which they have no private key? So I think that that is a separate issue that should not be held against an improvement like the one this patch would provide. Maybe it can be fixed by disallowing callbacks that would return incorrect data while renegotiation is in progress. Yours, Laurenz Albe From rt at openssl.org Mon Nov 2 11:26:16 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 02 Nov 2015 11:26:16 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <56374854.6030201@openssl.org> References: <562D5D30.9060909@openssl.org> <2967819.dUliAttKOr@pintsize.usersys.redhat.com> <56374854.6030201@openssl.org> Message-ID: On 02/11/15 10:16, Albe Laurenz via RT wrote: > Hubert Kario wrote: >> On Sunday 25 October 2015 22:52:36 Matt Caswell via RT wrote: >>> My concern though is broader than this specific case. I have given two >>> *examples* of exploits that we may open ourselves up to if we attempt >>> to process this application data without some fairly significant >>> refactoring of the code to separate out state currently in the >>> process of being negotiated from state for the current epoch. We >>> could probably patch things up to work around these two specific >>> examples but I worry that without the more significant refactoring >>> work, we may open ourselves up to other attacks that we haven't >>> thought of. >> >> unfortunately I have to agree. Those two examples show in rather clear >> terms that openssl as it is now in stable branches, can't be easily >> patched up to handle even specific situations of interleaved app data >> with handshake data in renegotiated handshakes. So breaking such >> connections is a safer option. >> >> That being said, Java behaviour is dangerous only if they expose to the >> application the "in negotiation" context instead of the "currently >> active" context. Not exactly easy to test. > > Sorry for being obtuse, but I don't see yet why these concerns should > prevent a simple fix. > > If interleaved application data are only allowed > a) before Change Cipher Spec > b) during a renegotiation, i.e., when the connection is encrypted > > your second example and similar exploits would not work, because the > application data would have to be encrypted with a cipher that is > known to be secure. I don't they you have understood the exploit. In my second example the *attacker* initiates the connection to the server *and* the subsequent renegotiation. Therefore the attacker already knows the keys negotiated during the initial handshake. She does *not* know the keys associated with the session that is going to be renegotiated. But she doesn't need to know those because she sends application data before that encryption context is in place, but after the new identity has been associated with the connection. This attack is about stealing an identity not about eavesdropping encrypted data. > > That leaves us with the first problem, namely that calls like > SSL_get_peer_certificate() will return incorrect values when renegotiation > has started but is not yet complete. > > I agree that the window for such a mistake will be widened somewhat > if the client were allowed to send application data after renegotiation > has started, but the problem already exists in the current code, right? No. In the current code, once renegotiation has started then no application data will be returned to the application until it has completed (or if application data is encountered then the connection will abort). So there will never be a scenario where application data is returned and the connection is in an intermediate state. > > What keeps the client from first sending the application data that cause > the dangerous call by the server and immediately afterwards starting a > renegotiation with a certificate for which they have no private key? > > So I think that that is a separate issue that should not be held against > an improvement like the one this patch would provide. > Maybe it can be fixed by disallowing callbacks that would return > incorrect data while renegotiation is in progress. It isn't just callbacks. A call to SSL_read will return to the calling application mid-renegotiation if application data is encountered. Matt From laurenz.albe at wien.gv.at Mon Nov 2 13:09:57 2015 From: laurenz.albe at wien.gv.at (Albe Laurenz) Date: Mon, 2 Nov 2015 13:09:57 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <562D5D30.9060909@openssl.org> <2967819.dUliAttKOr@pintsize.usersys.redhat.com> <56374854.6030201@openssl.org> Message-ID: Matt Caswell wrote: > On 02/11/15 10:16, Albe Laurenz via RT wrote: >> If interleaved application data are only allowed >> a) before Change Cipher Spec >> b) during a renegotiation, i.e., when the connection is encrypted >> >> your second example and similar exploits would not work, because the >> application data would have to be encrypted with a cipher that is >> known to be secure. > > I don't they you have understood the exploit. In my second example the > *attacker* initiates the connection to the server *and* the subsequent > renegotiation. Therefore the attacker already knows the keys negotiated > during the initial handshake. She does *not* know the keys associated > with the session that is going to be renegotiated. But she doesn't need > to know those because she sends application data before that encryption > context is in place, but after the new identity has been associated with > the connection. This attack is about stealing an identity not about > eavesdropping encrypted data. Thanks for the explanation, I had indeed misunderstood the problem. >> That leaves us with the first problem, namely that calls like >> SSL_get_peer_certificate() will return incorrect values when renegotiation >> has started but is not yet complete. >> >> I agree that the window for such a mistake will be widened somewhat >> if the client were allowed to send application data after renegotiation >> has started, but the problem already exists in the current code, right? > > No. In the current code, once renegotiation has started then no > application data will be returned to the application until it has > completed (or if application data is encountered then the connection > will abort). So there will never be a scenario where application data is > returned and the connection is in an intermediate state. > >> So I think that that is a separate issue that should not be held against >> an improvement like the one this patch would provide. >> Maybe it can be fixed by disallowing callbacks that would return >> incorrect data while renegotiation is in progress. > > It isn't just callbacks. A call to SSL_read will return to the calling > application mid-renegotiation if application data is encountered. I understand. Thanks for taking the time to explain. Yours, Laurenz Albe From rt at openssl.org Mon Nov 2 13:10:09 2015 From: rt at openssl.org (Albe Laurenz via RT) Date: Mon, 02 Nov 2015 13:10:09 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <562D5D30.9060909@openssl.org> <2967819.dUliAttKOr@pintsize.usersys.redhat.com> <56374854.6030201@openssl.org> Message-ID: Matt Caswell wrote: > On 02/11/15 10:16, Albe Laurenz via RT wrote: >> If interleaved application data are only allowed >> a) before Change Cipher Spec >> b) during a renegotiation, i.e., when the connection is encrypted >> >> your second example and similar exploits would not work, because the >> application data would have to be encrypted with a cipher that is >> known to be secure. > > I don't they you have understood the exploit. In my second example the > *attacker* initiates the connection to the server *and* the subsequent > renegotiation. Therefore the attacker already knows the keys negotiated > during the initial handshake. She does *not* know the keys associated > with the session that is going to be renegotiated. But she doesn't need > to know those because she sends application data before that encryption > context is in place, but after the new identity has been associated with > the connection. This attack is about stealing an identity not about > eavesdropping encrypted data. Thanks for the explanation, I had indeed misunderstood the problem. >> That leaves us with the first problem, namely that calls like >> SSL_get_peer_certificate() will return incorrect values when renegotiation >> has started but is not yet complete. >> >> I agree that the window for such a mistake will be widened somewhat >> if the client were allowed to send application data after renegotiation >> has started, but the problem already exists in the current code, right? > > No. In the current code, once renegotiation has started then no > application data will be returned to the application until it has > completed (or if application data is encountered then the connection > will abort). So there will never be a scenario where application data is > returned and the connection is in an intermediate state. > >> So I think that that is a separate issue that should not be held against >> an improvement like the one this patch would provide. >> Maybe it can be fixed by disallowing callbacks that would return >> incorrect data while renegotiation is in progress. > > It isn't just callbacks. A call to SSL_read will return to the calling > application mid-renegotiation if application data is encountered. I understand. Thanks for taking the time to explain. Yours, Laurenz Albe From tshort at akamai.com Mon Nov 2 14:06:11 2015 From: tshort at akamai.com (Short, Todd) Date: Mon, 2 Nov 2015 14:06:11 +0000 Subject: [openssl-dev] 1.0.2e release? Message-ID: <2EE7B742-53D5-400F-8938-E98648229E67@akamai.com> openssl-dev: It?s been almost 4 months, and ~127 commits since 1.0.2d went out the door. Are there plans for an upcoming 1.0.2e release? Thanks, -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Nov 2 19:09:45 2015 From: rt at openssl.org (yancm via RT) Date: Mon, 02 Nov 2015 19:09:45 +0000 Subject: [openssl-dev] [openssl.org #4118] Failed test 80 with OpenSSL 1.1.0-dev on NetBSD 6_Stable In-Reply-To: <43e6b158a2d90d0c3d37a17842953c08.squirrel@wm.sdf.org> References: <43e6b158a2d90d0c3d37a17842953c08.squirrel@wm.sdf.org> Message-ID: Recently I started getting a test that required PEM key interactive input. I used "ABC123". I am running the test suite as a non-root user. Failure is below: ../test/recipes/80-test_ca.t .............. Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ../test/recipes/80-test_ca.t .............. 1/4 # Failed test 'creating CA structure' # at ../test/recipes/80-test_ca.t line 25. # got: '256' # expected: '0' # Looks like you failed 1 test of 4. ../test/recipes/80-test_ca.t .............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/4 subtests (less 3 skipped subtests: 0 okay) ../test/recipes/80-test_cms.t ............. ok _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From ndrozd at vidyo.com Mon Nov 2 22:57:03 2015 From: ndrozd at vidyo.com (Natan Drozd) Date: Mon, 2 Nov 2015 22:57:03 +0000 Subject: [openssl-dev] FIPS support for Mac 64 bit and iOS 64 bit In-Reply-To: References: <553E1F4B.7090403@openssl.com> Message-ID: Hi Does openssl supports/has a supported version for iOS 64 bit? Thank You, Natan Drozd -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Nov 3 01:58:46 2015 From: rt at openssl.org (David Benjamin via RT) Date: Tue, 03 Nov 2015 01:58:46 +0000 Subject: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello In-Reply-To: References: Message-ID: Hey folks, We found a small DTLS bug while writing some tests. I think it affects 1.0.1 and 1.0.2 too, so I thought I'd send you a note. (Note sure about master. I'm unfamiliar with the new state machine mechanism.) In DTLS, each ClientHello is supposed to reset the handshake hash (in case of HelloVerifyRequest). The old state machine calls ssl3_init_finished_mac in the SSL3_ST_CW_CLNT_HELLO_* states. https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=ssl/d1_clnt.c;h=feeaf6d0656f5d0868121852d42b5037b8823111;hb=refs/heads/OpenSSL_1_0_2-stable#l317 If the ClientHello is fragmented and takes multiple iterations to write, the state machine is re-entered in SSL3_ST_CW_CLNT_HELLO_B, which calls ssl3_init_finished_mac again, and clobbers what was sampled to the handshake hash/buffer previously. This requires the transport return a retriable error on write, which probably isn't common for DTLS. It came up because WebRTC uses a custom BIO with a fixed-size buffer, so it can actually do this. Even then, a ClientHello is unlikely to fill up the buffer. Our tests repro'd it in BoringSSL by forcing every write to take two iterations. David -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Tue Nov 3 02:09:49 2015 From: rt at openssl.org (David Benjamin via RT) Date: Tue, 03 Nov 2015 02:09:49 +0000 Subject: [openssl-dev] [openssl.org #4120] CertificateStatus message is optional In-Reply-To: References: Message-ID: It seems unlikely I'll be getting around to doing another newsletter, but while I'm reporting bugs, here's another that came to mind: RFC 6066 is somewhat obnoxious and allows the server to decline to send CertificateStatus even after negotiating the extension. https://tools.ietf.org/html/rfc6066#section-8 Note that a server MAY also choose not to send a "CertificateStatus" message, even if has received a "status_request" extension in the client hello message and has sent a "status_request" extension in the server hello message. OpenSSL fails the handshake when the message is omitted. We had a report of an incompatibility because of this. I think it turned out IIS would negotiate certificate_status, send the ServerHello, and later try to find an OCSP response to staple. If it failed to do so, it would send no CertificateStatus. See also: https://crbug.com/478947 David -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From marquess at openssl.com Tue Nov 3 07:10:55 2015 From: marquess at openssl.com (Steve Marquess) Date: Tue, 3 Nov 2015 02:10:55 -0500 Subject: [openssl-dev] FIPS support for Mac 64 bit and iOS 64 bit In-Reply-To: References: <553E1F4B.7090403@openssl.com> Message-ID: <56385DFF.4050500@openssl.com> On 11/02/2015 05:57 PM, Natan Drozd wrote: > > > Hi > Does openssl supports/has a supported version for iOS 64 bit? >From the subject line I think you meant "does the OpenSSL FIPS Object Module" support iOS 64 bits. Take a look at Table 2 of the Security Policy, platforms 103/104: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From rt at openssl.org Tue Nov 3 09:26:08 2015 From: rt at openssl.org (Srinivas Thota via RT) Date: Tue, 03 Nov 2015 09:26:08 +0000 Subject: [openssl-dev] [openssl.org #4103] Valgrind reported memory leak in X509_PUBKEY_get In-Reply-To: References: Message-ID: Please ignore this. Issue found in user code. Thank you so much. On Thu, Oct 22, 2015 at 12:18 AM, Salz, Rich via RT wrote: > > I am trying figure out valgrind report leak. in openssl 1.0.1c. > > You don't have enough of the backtrace for us to reproduce it. Please add > a simple demo program. > > From rt at openssl.org Tue Nov 3 09:43:13 2015 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 03 Nov 2015 09:43:13 +0000 Subject: [openssl-dev] [openssl.org #4103] Valgrind reported memory leak in X509_PUBKEY_get In-Reply-To: References: Message-ID: closing per request of submittor. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Nov 3 10:04:28 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 03 Nov 2015 10:04:28 +0000 Subject: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello In-Reply-To: <563886AA.4000905@openssl.org> References: <563886AA.4000905@openssl.org> Message-ID: Hi David, On 03/11/15 01:58, David Benjamin via RT wrote: > Hey folks, > > We found a small DTLS bug while writing some tests. I think it affects > 1.0.1 and 1.0.2 too, so I thought I'd send you a note. (Note sure about > master. I'm unfamiliar with the new state machine mechanism.) Just from looking at the code I think master should be ok. In the new state machine, writes go through a "pre-work" phase where ssl3_init_finished_mac is called for DTLS. This pre-work is skipped if the actual write needs a retry. Matt From rt at openssl.org Tue Nov 3 16:16:37 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 03 Nov 2015 16:16:37 +0000 Subject: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello In-Reply-To: <5638DDE0.3060107@openssl.org> References: <5638DDE0.3060107@openssl.org> Message-ID: Hi David On 03/11/15 01:58, David Benjamin via RT wrote: > Hey folks, > > We found a small DTLS bug while writing some tests. I think it affects > 1.0.1 and 1.0.2 too, so I thought I'd send you a note. (Note sure about > master. I'm unfamiliar with the new state machine mechanism.) > > In DTLS, each ClientHello is supposed to reset the handshake hash (in case > of HelloVerifyRequest). The old state machine calls ssl3_init_finished_mac > in the SSL3_ST_CW_CLNT_HELLO_* states. > > https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=ssl/d1_clnt.c;h=feeaf6d0656f5d0868121852d42b5037b8823111;hb=refs/heads/OpenSSL_1_0_2-stable#l317 > > If the ClientHello is fragmented and takes multiple iterations to write, > the state machine is re-entered in SSL3_ST_CW_CLNT_HELLO_B, which > calls ssl3_init_finished_mac again, and clobbers what was sampled to the > handshake hash/buffer previously. > > This requires the transport return a retriable error on write, which > probably isn't common for DTLS. It came up because WebRTC uses a custom BIO > with a fixed-size buffer, so it can actually do this. Even then, a > ClientHello is unlikely to fill up the buffer. Our tests repro'd it in > BoringSSL by forcing every write to take two iterations. I can confirm this issue on 1.0.2 (and almost certainly 1.0.1). It does not affect master. Whilst investigating this I noticed another bug which is actually probably more significant. My eyeball only look at the BoringSSL source suggests that it is there too, so I'm not sure why you haven't seen it in the test that you mentioned. If a retry occurs on a second or subsequent fragment of a handshake message then when we do the retry the wrong fragment offset and length is used. The impact isn't that great because the messages got dropped by the peer, and then when they get retransmitted they have the correct values inserted...so the handshake succeeds - but it gets delayed. Perhaps that is why you don't see it in your test. This second issue occurs in all branches. One other related point is that fragmenting ClientHellos is probably a bad idea. The whole ClientHello/HelloVerifyRequest mechanism is meant to be implemented without storing state on the server. That isn't possible if you have to deal with fragment reassembly. In the new DTLSv1_listen implementation in master we drop fragmented ClientHellos. Patch attached for these two issues (patch against 1.0.2). Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: dtls-frag-retry.patch Type: text/x-patch Size: 3085 bytes Desc: not available URL: From rt at openssl.org Tue Nov 3 17:43:05 2015 From: rt at openssl.org (David Benjamin via RT) Date: Tue, 03 Nov 2015 17:43:05 +0000 Subject: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello In-Reply-To: References: <5638DDE0.3060107@openssl.org> Message-ID: On Tue, Nov 3, 2015 at 11:16 AM Matt Caswell via RT wrote: > Whilst investigating this I noticed another bug which is actually > probably more significant. My eyeball only look at the BoringSSL source > suggests that it is there too, so I'm not sure why you haven't seen it > in the test that you mentioned. > > If a retry occurs on a second or subsequent fragment of a handshake > message then when we do the retry the wrong fragment offset and length > is used. The impact isn't that great because the messages got dropped by > the peer, and then when they get retransmitted they have the correct > values inserted...so the handshake succeeds - but it gets delayed. > Perhaps that is why you don't see it in your test. > Our tests are pretty strict and deterministic (clock is mocked out, Go DTLS half is intentionally much stricter than a real impl), so it actually fails if packets are dropped that aren't supposed to be. I think it's actually because my async tests, uh, didn't stress the low MTU case at all. :-) Thanks! (The handshake hash bug requires a fragmented ClientHello to trigger in OpenSSL because you only update the handshake hash as it gets written, whereas BoringSSL updates it up-front to simplify a few things. I actually didn't think much about fragmentation when working on it our end and only realized it was a precondition for you later.) In fact, apparently I'd noticed frag_off was messed up before, added TODOs, and forgot about it. :-) I guess this must have been the other reason I'd previously assumed retrying writes in the DTLS code didn't work at all. It mostly doesn't. https://boringssl.googlesource.com/boringssl/+/master/ssl/d1_both.c#285 I'm not sure that fix quite works though. If BIO_flush completes asynchronously (hrm, it's missing an rwstate update), then I believe you'll be in a state where you *do* want to repeat the init_off / init_num adjust. You might be able to get away with using init_off/init_num with some minor tweaks? Another problem: because the fragment headers clobber whatever was already written, msg_callback sees garbage. Also this function is used for the unfragmented ChangeCipherSpec, so it's even messier. I dunno, this code is too stateful by several orders of magnitude. I think I'm going to toy with rewriting it now rather than think too hard about the existing mess. > This second issue occurs in all branches. > > One other related point is that fragmenting ClientHellos is probably a > bad idea. The whole ClientHello/HelloVerifyRequest mechanism is meant to > be implemented without storing state on the server. That isn't possible > if you have to deal with fragment reassembly. In the new DTLSv1_listen > implementation in master we drop fragmented ClientHellos. > Yeah, this part of DTLS (like much of it) is woefully underspecified. We keep stuffing things into ClientHellos, so if one does need to support fragmented ones, I think the right way to do stateless HelloVerifyRequest is to silently drop all non-initial ClientHello fragments and require the initial one be large enough to include the client_random and whatever else you figure into the cookie. David From openssl-users at dukhovni.org Tue Nov 3 18:28:41 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 3 Nov 2015 18:28:41 +0000 Subject: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello In-Reply-To: References: <5638DDE0.3060107@openssl.org> Message-ID: <20151103182841.GN18315@mournblade.imrryr.org> On Tue, Nov 03, 2015 at 04:16:37PM +0000, Matt Caswell via RT wrote: > One other related point is that fragmenting ClientHellos is probably a > bad idea. The whole ClientHello/HelloVerifyRequest mechanism is meant to > be implemented without storing state on the server. That isn't possible > if you have to deal with fragment reassembly. In the new DTLSv1_listen > implementation in master we drop fragmented ClientHellos. I assume you mean fragmentation across multiple TLS record layer packets, not UDP fragmentation into multiple IP layer fragments... Presumably the kernel delivers reassembled UDP datagrams to user-land, so OpenSSL's DTLS never sees UDP fragmentation. I expect that DTLS is allowed to use UDP datagrams that are larger than the IP MTU, but if these MUST be fragmented at TLS record layer instead, then client HELLO packets can't carry very large extensions, and in particular session tickets could run into trouble... I don't know whether the code that inserts the TLS padding extension is common to the TLS and DTLS code paths, ideally DTLS should at least avoid bloat from the padding extension. -- Viktor. From matt at openssl.org Tue Nov 3 18:55:08 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 3 Nov 2015 18:55:08 +0000 Subject: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello In-Reply-To: <20151103182841.GN18315@mournblade.imrryr.org> References: <5638DDE0.3060107@openssl.org> <20151103182841.GN18315@mournblade.imrryr.org> Message-ID: <5639030C.5050500@openssl.org> On 03/11/15 18:28, Viktor Dukhovni wrote: > On Tue, Nov 03, 2015 at 04:16:37PM +0000, Matt Caswell via RT wrote: > >> One other related point is that fragmenting ClientHellos is probably a >> bad idea. The whole ClientHello/HelloVerifyRequest mechanism is meant to >> be implemented without storing state on the server. That isn't possible >> if you have to deal with fragment reassembly. In the new DTLSv1_listen >> implementation in master we drop fragmented ClientHellos. > > I assume you mean fragmentation across multiple TLS record layer > packets, not UDP fragmentation into multiple IP layer fragments... Yes - multiple DTLS record layer packets. > > Presumably the kernel delivers reassembled UDP datagrams to user-land, > so OpenSSL's DTLS never sees UDP fragmentation. Yes. > > I expect that DTLS is allowed to use UDP datagrams that are larger > than the IP MTU, but if these MUST be fragmented at TLS record > layer instead, then client HELLO packets can't carry very large > extensions, and in particular session tickets could run into trouble... OpenSSL tries to keep DTLS packets within the MTU if possible. I like David's idea of dropping non-initial ClientHello fragments and only requiring that the cookie needed for ClientHello/HelloVerifyRequest is kept within the initial fragment, rather than requiring that the whole ClientHello fits into a single fragment. I'll take a look at that. Matt From rt at openssl.org Tue Nov 3 21:15:12 2015 From: rt at openssl.org (David Benjamin via RT) Date: Tue, 03 Nov 2015 21:15:12 +0000 Subject: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello In-Reply-To: References: <5638DDE0.3060107@openssl.org> Message-ID: On Tue, Nov 3, 2015 at 12:42 PM David Benjamin wrote: > I'm not sure that fix quite works though. If BIO_flush completes > asynchronously (hrm, it's missing an rwstate update), then I believe you'll > be in a state where you *do* want to repeat the init_off / init_num adjust. > You might be able to get away with using init_off/init_num with some minor > tweaks? Another problem: because the fragment headers clobber whatever was > already written, msg_callback sees garbage. Also this function is used for > the unfragmented ChangeCipherSpec, so it's even messier. > > I dunno, this code is too stateful by several orders of magnitude. I think > I'm going to toy with rewriting it now rather than think too hard about the > existing mess. > This still needs to be reviewed, but here's a go at a cleaner version on our end. It passes our test suite, even after modifying it to stress the async write + low MTU case. (And the old code indeed does not.) https://boringssl-review.googlesource.com/#/c/6420/ https://boringssl-review.googlesource.com/#/c/6421/ David From rt at openssl.org Wed Nov 4 12:04:54 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 04 Nov 2015 12:04:54 +0000 Subject: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello In-Reply-To: <5639F45D.7060702@openssl.org> References: <5638DDE0.3060107@openssl.org> <5639F45D.7060702@openssl.org> Message-ID: On 03/11/15 17:43, David Benjamin via RT wrote: > I'm not sure that fix quite works though. If BIO_flush completes > asynchronously Ahhh, yes good point. Updated patch attached. > (hrm, it's missing an rwstate update), Yes, just discovered that myself and then came back and reread your email to find out you already pointed it out! Also addressed in updated patch. > then I believe you'll > be in a state where you *do* want to repeat the init_off / init_num adjust. > You might be able to get away with using init_off/init_num with some minor > tweaks? Another problem: because the fragment headers clobber whatever was > already written, msg_callback sees garbage. Yuck. Not addressed that issue yet. I'll deal with that separately. > Yeah, this part of DTLS (like much of it) is woefully underspecified. We > keep stuffing things into ClientHellos, so if one does need to support > fragmented ones, I think the right way to do stateless HelloVerifyRequest > is to silently drop all non-initial ClientHello fragments and require the > initial one be large enough to include the client_random and whatever else > you figure into the cookie. I really like that idea. I'll take a look at doing that in the new DTLSv1_listen code. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: dtls-frag-retry2.patch Type: text/x-patch Size: 6590 bytes Desc: not available URL: From rt at openssl.org Wed Nov 4 14:23:51 2015 From: rt at openssl.org (Marcus Meissner via RT) Date: Wed, 04 Nov 2015 14:23:51 +0000 Subject: [openssl-dev] [openssl.org #4121] avoid configuring openssl twice In-Reply-To: <20151104140424.GC16133@suse.de> References: <20151104140424.GC16133@suse.de> Message-ID: Hi, In a mix of various libraries using openssl it can happen that OPENSSL_config is called multiple times. Usually this works, but e.g. if you have engines configured, the second load of engines will not work. OPENSSL_config checks openssl_configured on begin, but does not set it when done. (only in OPENSSL_no_config). So lets set it at the end of OPENSSL_config. Sent as https://github.com/openssl/openssl/pull/466 Ciao, Marcus -- Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Nov 4 15:30:29 2015 From: rt at openssl.org (David Benjamin via RT) Date: Wed, 04 Nov 2015 15:30:29 +0000 Subject: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello In-Reply-To: References: <5638DDE0.3060107@openssl.org> <5639F45D.7060702@openssl.org> Message-ID: On Wed, Nov 4, 2015 at 7:04 AM Matt Caswell via RT wrote: > > > On 03/11/15 17:43, David Benjamin via RT wrote: > > > I'm not sure that fix quite works though. If BIO_flush completes > > asynchronously > > Ahhh, yes good point. Updated patch attached. > > > (hrm, it's missing an rwstate update), > > Yes, just discovered that myself and then came back and reread your > email to find out you already pointed it out! Also addressed in updated > patch. > The new patch seems to almost work. I merged it into our codebase since we hadn't diverged too much on that function yet and ran it against our tests (fixed to actually stress low MTUs). The s->init_off <= DTLS1_HM_HEADER_LENGTH assertion is only true in the frag_off > 0 case. After moving it there, everything passes. For reference, here's the merged version: https://boringssl-review.googlesource.com/#/c/6424/ David PS: By the way, you might want to consider doing something similar to test all the resume points, since they're apparently pretty subtle and hard to get right sometimes. :-) I added an async mode to our tests which installs a filter BIO that only lets one byte/datagram through at a time. https://boringssl.googlesource.com/boringssl/+/a97b737fb09509dcedf0d15b51b60d2349821605/ssl/test/async_bio.cc It also makes every callback take two steps where possible. https://boringssl.googlesource.com/boringssl/+/a97b737fb09509dcedf0d15b51b60d2349821605/ssl/test/bssl_shim.cc#510 That's driven like this: https://boringssl.googlesource.com/boringssl/+/a97b737fb09509dcedf0d15b51b60d2349821605/ssl/test/bssl_shim.cc#802 https://boringssl.googlesource.com/boringssl/+/a97b737fb09509dcedf0d15b51b60d2349821605/ssl/test/bssl_shim.cc#873 Then that gets run through a series of tests intended to cover all the various possible handshake shapes. https://boringssl.googlesource.com/boringssl/+/a97b737fb09509dcedf0d15b51b60d2349821605/ssl/test/runner/runner.go#2539 It's worked pretty well, assuming I remember to cover all the interesting cases. (Apparently I missed one this time around, so it's not perfect. :-) Still, it's caught a lot of mistakes early.) From rt at openssl.org Wed Nov 4 17:04:41 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 04 Nov 2015 17:04:41 +0000 Subject: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello In-Reply-To: <563A3AA4.408@openssl.org> References: <5638DDE0.3060107@openssl.org> <5639F45D.7060702@openssl.org> <563A3AA4.408@openssl.org> Message-ID: On 04/11/15 15:30, David Benjamin via RT wrote: > On Wed, Nov 4, 2015 at 7:04 AM Matt Caswell via RT wrote: > >> >> >> On 03/11/15 17:43, David Benjamin via RT wrote: >> >>> I'm not sure that fix quite works though. If BIO_flush completes >>> asynchronously >> >> Ahhh, yes good point. Updated patch attached. >> >>> (hrm, it's missing an rwstate update), >> >> Yes, just discovered that myself and then came back and reread your >> email to find out you already pointed it out! Also addressed in updated >> patch. >> > > The new patch seems to almost work. I merged it into our codebase since we > hadn't diverged too much on that function yet and ran it against our tests > (fixed to actually stress low MTUs). The s->init_off <= > DTLS1_HM_HEADER_LENGTH assertion is only true in the frag_off > 0 case. > After moving it there, everything passes. > > For reference, here's the merged version: > https://boringssl-review.googlesource.com/#/c/6424/ Great! Thanks David. Matt From dmitry at addlive.com Fri Nov 6 01:42:12 2015 From: dmitry at addlive.com (Dmitry Sobinov) Date: Fri, 6 Nov 2015 12:42:12 +1100 Subject: [openssl-dev] [BUG] Data race in md_rand.c functions Message-ID: We use OpenSSL for DTLS and for general random numbers generation. While checking our app with Clang Thread Sanitizer, we discovered following data race: WARNING: ThreadSanitizer: data race (pid=20055) Read of size 4 at 0x7f14adbb7f98 by thread T18: #0 ssleay_rand_add /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/md_rand.c:220 (test_client+0x000000dd242a) #1 RAND_add /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/rand_lib.c:152 (test_client+0x000000c795be) #2 dtls1_connect /home/dmitry.sobinov/builds/openssl-1.0.2d/ssl/d1_clnt.c:174 (test_client+0x000000f4850a) #3 SSL_do_handshake /home/dmitry.sobinov/builds/openssl-1.0.2d/ssl/ssl_lib.c:2768 (test_client+0x000000f701ec) #4 DtlsSrtpTransport::handshakeIteration() /home/dmitry.sobinov/__/src/DtlsSrtpTransport.cpp:328 (test_client+0x00000079ef88) Previous write of size 4 at 0x7f14adbb7f98 by thread T41 (mutexes: write M869): #0 ssleay_rand_bytes /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/md_rand.c:392 (test_client+0x000000dd2e1f) #1 ssleay_rand_nopseudo_bytes /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/md_rand.c:536 (test_client+0x000000dd22cb) #2 RAND_bytes /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/rand_lib.c:159 (test_client+0x000000c7965a) #3 utils::generateRandomBytes(unsigned char*, unsigned long) /home/dmitry.sobinov/__/src/OpenSSLHelpers.cpp:45 (test_client+0x00000078a697) #4 unsigned short utils::random() /home/dmitry.sobinov/__/include/utils/OpenSSLHelpers.h:42 (test_client+0x0000005a4bff) Static global variable crypto_lock_rand is not protected by mutex or set as atomic. AFAIK it's undefined behaviour in c/c++. OpenSSL was built with TSan instrumentation. Thanks, Dmitry Sobinov -------------- next part -------------- An HTML attachment was scrubbed... URL: From tshort at akamai.com Fri Nov 6 14:31:03 2015 From: tshort at akamai.com (Short, Todd) Date: Fri, 6 Nov 2015 14:31:03 +0000 Subject: [openssl-dev] [BUG] Data race in md_rand.c functions In-Reply-To: References: Message-ID: Do you set any of the locking functions and/or do you configure with no-locking? CRYPTO_set_locking_callback() CRYPTO_set_add_lock_callback() see: https://www.openssl.org/docs/manmaster/crypto/threads.html -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Nov 5, 2015, at 8:42 PM, Dmitry Sobinov > wrote: We use OpenSSL for DTLS and for general random numbers generation. While checking our app with Clang Thread Sanitizer, we discovered following data race: WARNING: ThreadSanitizer: data race (pid=20055) Read of size 4 at 0x7f14adbb7f98 by thread T18: #0 ssleay_rand_add /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/md_rand.c:220 (test_client+0x000000dd242a) #1 RAND_add /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/rand_lib.c:152 (test_client+0x000000c795be) #2 dtls1_connect /home/dmitry.sobinov/builds/openssl-1.0.2d/ssl/d1_clnt.c:174 (test_client+0x000000f4850a) #3 SSL_do_handshake /home/dmitry.sobinov/builds/openssl-1.0.2d/ssl/ssl_lib.c:2768 (test_client+0x000000f701ec) #4 DtlsSrtpTransport::handshakeIteration() /home/dmitry.sobinov/__/src/DtlsSrtpTransport.cpp:328 (test_client+0x00000079ef88) Previous write of size 4 at 0x7f14adbb7f98 by thread T41 (mutexes: write M869): #0 ssleay_rand_bytes /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/md_rand.c:392 (test_client+0x000000dd2e1f) #1 ssleay_rand_nopseudo_bytes /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/md_rand.c:536 (test_client+0x000000dd22cb) #2 RAND_bytes /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/rand_lib.c:159 (test_client+0x000000c7965a) #3 utils::generateRandomBytes(unsigned char*, unsigned long) /home/dmitry.sobinov/__/src/OpenSSLHelpers.cpp:45 (test_client+0x00000078a697) #4 unsigned short utils::random() /home/dmitry.sobinov/__/include/utils/OpenSSLHelpers.h:42 (test_client+0x0000005a4bff) Static global variable crypto_lock_rand is not protected by mutex or set as atomic. AFAIK it's undefined behaviour in c/c++. OpenSSL was built with TSan instrumentation. Thanks, Dmitry Sobinov _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From tarunpolisetti at gmail.com Fri Nov 6 16:46:56 2015 From: tarunpolisetti at gmail.com (T@Run..............! Polisetty) Date: Fri, 6 Nov 2015 22:16:56 +0530 Subject: [openssl-dev] Openssl Memory Leak Message-ID: Hai All, We are hitting at critical Memory leaks in ssl3_get_client_certificate() where are not able to run calls in load. The backtrace of the leak is 291 bytes in 97 blocks are indirectly lost in loss record 2,354 of 3,052 ==31717== at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==31717== by 0x516C4FE: default_malloc_ex (mem.c:79) ==31717== by 0x516CBD5: CRYPTO_malloc (mem.c:342) ==31717== by 0x5228977: c2i_ASN1_OBJECT (a_object.c:315) ==31717== by 0x523B86B: asn1_ex_c2i (tasn_dec.c:874) ==31717== by 0x523B6BE: asn1_d2i_ex_primitive (tasn_dec.c:831) ==31717== by 0x5239DBD: ASN1_item_ex_d2i (tasn_dec.c:207) ==31717== by 0x523B187: asn1_template_noexp_d2i (tasn_dec.c:691) ==31717== by 0x523AD6D: asn1_template_ex_d2i (tasn_dec.c:579) ==31717== by 0x523A815: ASN1_item_ex_d2i (tasn_dec.c:443) ==31717== by 0x523B009: asn1_template_noexp_d2i (tasn_dec.c:663) ==31717== by 0x523AC7C: asn1_template_ex_d2i (tasn_dec.c:555) ==31717== by 0x523A815: ASN1_item_ex_d2i (tasn_dec.c:443) ==31717== by 0x523B187: asn1_template_noexp_d2i (tasn_dec.c:691) ==31717== by 0x523AD6D: asn1_template_ex_d2i (tasn_dec.c:579) ==31717== by 0x523A815: ASN1_item_ex_d2i (tasn_dec.c:443) ==31717== by 0x5239BAE: ASN1_item_d2i (tasn_dec.c:146) ==31717== by 0x5232A80: d2i_X509 (x_x509.c:154) ==31717== by 0x4E54775: ssl3_get_client_certificate (s3_srvr.c:3174) ==31717== by 0x4E72D2E: dtls1_accept (d1_srvr.c:605) ==31717== by 0x4E7A0DC: dtls1_read_bytes (d1_pkt.c:811) ==31717== by 0x4E5F47C: ssl3_read_internal (s3_lib.c:4246) ==31717== by 0x4E5F52B: ssl3_read (s3_lib.c:4270) ==31717== by 0x4E81F87: SSL_read (ssl_lib.c:1021) Can anyone let us know about the leaks and will SSL_FREE() will free the above memory. Please help . Regards Satya -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry at addlive.com Sat Nov 7 05:08:41 2015 From: dmitry at addlive.com (Dmitry Sobinov) Date: Sat, 7 Nov 2015 16:08:41 +1100 Subject: [openssl-dev] [BUG] Data race in md_rand.c functions In-Reply-To: References: Message-ID: It's set by boost::asio lazily on first use which happens early in the app lifetime (before any use of DTLS). On Sat, Nov 7, 2015 at 1:31 AM, Short, Todd wrote: > Do you set any of the locking functions and/or do you configure with > no-locking? > > CRYPTO_set_locking_callback() > CRYPTO_set_add_lock_callback() > > see: https://www.openssl.org/docs/manmaster/crypto/threads.html > > > -- > -Todd Short > // tshort at akamai.com > // "One if by land, two if by sea, three if by the Internet." > > On Nov 5, 2015, at 8:42 PM, Dmitry Sobinov wrote: > > We use OpenSSL for DTLS and for general random numbers generation. While > checking our app with Clang Thread Sanitizer, we discovered following data > race: > > WARNING: ThreadSanitizer: data race (pid=20055) > Read of size 4 at 0x7f14adbb7f98 by thread T18: > #0 ssleay_rand_add > /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/md_rand.c:220 > (test_client+0x000000dd242a) > #1 RAND_add > /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/rand_lib.c:152 > (test_client+0x000000c795be) > #2 dtls1_connect > /home/dmitry.sobinov/builds/openssl-1.0.2d/ssl/d1_clnt.c:174 > (test_client+0x000000f4850a) > #3 SSL_do_handshake > /home/dmitry.sobinov/builds/openssl-1.0.2d/ssl/ssl_lib.c:2768 > (test_client+0x000000f701ec) > #4 DtlsSrtpTransport::handshakeIteration() > /home/dmitry.sobinov/__/src/DtlsSrtpTransport.cpp:328 > (test_client+0x00000079ef88) > > Previous write of size 4 at 0x7f14adbb7f98 by thread T41 (mutexes: write > M869): > #0 ssleay_rand_bytes > /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/md_rand.c:392 > (test_client+0x000000dd2e1f) > #1 ssleay_rand_nopseudo_bytes > /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/md_rand.c:536 > (test_client+0x000000dd22cb) > #2 RAND_bytes > /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/rand_lib.c:159 > (test_client+0x000000c7965a) > #3 utils::generateRandomBytes(unsigned char*, unsigned long) > /home/dmitry.sobinov/__/src/OpenSSLHelpers.cpp:45 > (test_client+0x00000078a697) > #4 unsigned short utils::random() > /home/dmitry.sobinov/__/include/utils/OpenSSLHelpers.h:42 > (test_client+0x0000005a4bff) > > > Static global variable crypto_lock_rand is not protected by mutex or set > as atomic. AFAIK it's undefined behaviour in c/c++. > OpenSSL was built with TSan instrumentation. > > > Thanks, > Dmitry Sobinov > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -- --- Dmitry Sobinov AddLive.com Live video and voice for your application -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sun Nov 8 11:37:53 2015 From: rt at openssl.org (tosif tamboli via RT) Date: Sun, 08 Nov 2015 11:37:53 +0000 Subject: [openssl-dev] [openssl.org #4123] Query regarding dummy variable inside crypto In-Reply-To: References: Message-ID: Hi , I am compiling crypto in openssl for vxWorks version 5.4 with 5.5.1 it compiles well But with 5.4 it gives error for below files bn_depr.c ccppc: Internal compiler error: program cc1 got fatal signal 6 When checked it gives error for location static void *dummy=&dummy; When I comment it then compiles well. but not getting why it's required if it's not being used anywhere. Can you please provide your inputs for above? Thanks & regards, Tosif -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sun Nov 8 11:37:55 2015 From: rt at openssl.org (Tomas Mraz via RT) Date: Sun, 08 Nov 2015 11:37:55 +0000 Subject: [openssl-dev] [openssl.org #4124] Illegal instruction when using aes-ni-sha256 stitched implementation on AMD CPU In-Reply-To: <1446731461.2626.27.camel@redhat.com> References: <1446731461.2626.27.camel@redhat.com> Message-ID: The aes-ni-sha256 stitched implementation causes SIGILL on AMD A4-6210. It is caused by not using the AVX+SSSE3 code path for non-Intel CPUs although the CPU seems to be fully capable of running it. The ia32cap vector is 0x7ED8220B078BFFFF but when you set it explicitly with OPENSSL_ia32cap=0x7ED8220B478BFFFF (i.e. the Intel CPU bit is set) it works fine and the AVX+SSSE3 codepath is taken. See also https://bugzilla.redhat.com/show_bug.cgi?id=1278194 for details. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sun Nov 8 11:37:53 2015 From: rt at openssl.org (tosif tamboli via RT) Date: Sun, 08 Nov 2015 11:37:53 +0000 Subject: [openssl-dev] [openssl.org #4122] Re: Query regarding dummy variable inside crypto In-Reply-To: References: Message-ID: Hi, Can you please provide your inputs Thanks, Tosif On Wed, Nov 4, 2015 at 1:59 PM, tosif tamboli wrote: > Hi , > I am compiling crypto in openssl for vxWorks version 5.4 > with 5.5.1 it compiles well > But with 5.4 it gives error for below files > bn_depr.c > ccppc: Internal compiler error: program cc1 got fatal signal 6 > > When checked it gives error for location > static void *dummy=&dummy; > When I comment it then compiles well. but not getting why it's required if > it's not being used anywhere. > > Can you please provide your inputs for above? > > Thanks & regards, > Tosif > > -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sun Nov 8 11:37:56 2015 From: rt at openssl.org (Leonidas Da Silva Barbosa via RT) Date: Sun, 08 Nov 2015 11:37:56 +0000 Subject: [openssl-dev] [openssl.org #4126] [PATCH] Re-arrange code to improve performance for z systems In-Reply-To: <20151105152043.GA10466@bluepex.com> References: <20151105152043.GA10466@bluepex.com> Message-ID: This patch does a re-arrangement in order to circumvent a performance degradation of more than 20%. Measurements with the fix included showed performance improvements of the required size on zEC12 and z13. Signed-off-by: Leonidas Da Silva Barbosa --- crypto/bn/asm/s390x.S | 35 ++++++++++++++++++++--------------- 1 file changed, 20 insertions(+), 15 deletions(-) diff --git a/crypto/bn/asm/s390x.S b/crypto/bn/asm/s390x.S index 43fcb79..c0e1fe9 100755 --- a/crypto/bn/asm/s390x.S +++ b/crypto/bn/asm/s390x.S @@ -33,35 +33,40 @@ bn_mul_add_words: .Loop4_madd: lg %r7,0(%r2,%r3) // ap[i] + lg %r9,8(%r2,%r3) + mlgr %r6,%r5 // *=w alcgr %r7,%r8 // +=carry - alcgr %r6,zero + alcgr %r6,%r0 + mlgr %r8,%r5 + alg %r7,0(%r2,%r1) // +=rp[i] stg %r7,0(%r2,%r1) // rp[i]= + lg %r7,0x10(%r2,%r3) - lg %r9,8(%r2,%r3) - mlgr %r8,%r5 alcgr %r9,%r6 - alcgr %r8,zero + alcgr %r8,%r0 + alg %r9,8(%r2,%r1) stg %r9,8(%r2,%r1) + lg %r9,0x18(%r2,%r3) - lg %r7,16(%r2,%r3) mlgr %r6,%r5 alcgr %r7,%r8 - alcgr %r6,zero - alg %r7,16(%r2,%r1) - stg %r7,16(%r2,%r1) + alcgr %r6,%r0 + mlgr %r8,%r5 + + alg %r7,0x10(%r2,%r1) + stg %r7,0x10(%r2,%r1) - lg %r9,24(%r2,%r3) - mlgr %r8,%r5 alcgr %r9,%r6 - alcgr %r8,zero - alg %r9,24(%r2,%r1) - stg %r9,24(%r2,%r1) + alcgr %r8,%r0 - la %r2,32(%r2) // i+=4 - brct %r4,.Loop4_madd + alg %r9,0x18(%r2,%r1) + stg %r9,0x18(%r2,%r1) + la %r2,0x20(%r0,%r2) // i+=4 + + brct %r4,.Loop4_madd la %r10,1(%r10) // see if len%4 is zero ... brct %r10,.Loop1_madd // without touching condition code:-) -- 1.8.3.1 _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sun Nov 8 11:37:56 2015 From: rt at openssl.org (Dmitry Sobinov via RT) Date: Sun, 08 Nov 2015 11:37:56 +0000 Subject: [openssl-dev] [openssl.org #4127] [BUG] Data race in md_rand.c functions In-Reply-To: References: Message-ID: We use OpenSSL for DTLS and for general random numbers generation. While checking our app with Clang Thread Sanitizer, we discovered following data race: WARNING: ThreadSanitizer: data race (pid=20055) Read of size 4 at 0x7f14adbb7f98 by thread T18: #0 ssleay_rand_add /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/md_rand.c:220 (test_client+0x000000dd242a) #1 RAND_add /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/rand_lib.c:152 (test_client+0x000000c795be) #2 dtls1_connect /home/dmitry.sobinov/builds/openssl-1.0.2d/ssl/d1_clnt.c:174 (test_client+0x000000f4850a) #3 SSL_do_handshake /home/dmitry.sobinov/builds/openssl-1.0.2d/ssl/ssl_lib.c:2768 (test_client+0x000000f701ec) #4 DtlsSrtpTransport::handshakeIteration() /home/dmitry.sobinov/__/src/DtlsSrtpTransport.cpp:328 (test_client+0x00000079ef88) Previous write of size 4 at 0x7f14adbb7f98 by thread T41 (mutexes: write M869): #0 ssleay_rand_bytes /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/md_rand.c:392 (test_client+0x000000dd2e1f) #1 ssleay_rand_nopseudo_bytes /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/md_rand.c:536 (test_client+0x000000dd22cb) #2 RAND_bytes /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/rand_lib.c:159 (test_client+0x000000c7965a) #3 utils::generateRandomBytes(unsigned char*, unsigned long) /home/dmitry.sobinov/__/src/OpenSSLHelpers.cpp:45 (test_client+0x00000078a697) #4 unsigned short utils::random() /home/dmitry.sobinov/__/include/utils/OpenSSLHelpers.h:42 (test_client+0x0000005a4bff) Static global variable crypto_lock_rand is not protected by mutex or set as atomic. AFAIK it's undefined behaviour in c/c++. OpenSSL was built with TSan instrumentation. Thanks, Dmitry Sobinov -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sun Nov 8 11:37:57 2015 From: rt at openssl.org (Leonidas Da Silva Barbosa via RT) Date: Sun, 08 Nov 2015 11:37:57 +0000 Subject: [openssl-dev] [openssl.org #4128] [PATCH] Re-arrange code to improve performance for z systems In-Reply-To: <20151106142417.GA24161@bluepex.com> References: <20151106142417.GA24161@bluepex.com> Message-ID: This patch does a re-arrangement in order to circumvent a performance degradation of more than 20%. Measurements with the fix included showed performance improvements of the required size on zEC12 and z13. Signed-off-by: Leonidas Da Silva Barbosa --- crypto/bn/asm/s390x.S | 35 ++++++++++++++++++++--------------- 1 file changed, 20 insertions(+), 15 deletions(-) diff --git a/crypto/bn/asm/s390x.S b/crypto/bn/asm/s390x.S index 43fcb79..c0e1fe9 100755 --- a/crypto/bn/asm/s390x.S +++ b/crypto/bn/asm/s390x.S @@ -33,35 +33,40 @@ bn_mul_add_words: .Loop4_madd: lg %r7,0(%r2,%r3) // ap[i] + lg %r9,8(%r2,%r3) + mlgr %r6,%r5 // *=w alcgr %r7,%r8 // +=carry - alcgr %r6,zero + alcgr %r6,%r0 + mlgr %r8,%r5 + alg %r7,0(%r2,%r1) // +=rp[i] stg %r7,0(%r2,%r1) // rp[i]= + lg %r7,0x10(%r2,%r3) - lg %r9,8(%r2,%r3) - mlgr %r8,%r5 alcgr %r9,%r6 - alcgr %r8,zero + alcgr %r8,%r0 + alg %r9,8(%r2,%r1) stg %r9,8(%r2,%r1) + lg %r9,0x18(%r2,%r3) - lg %r7,16(%r2,%r3) mlgr %r6,%r5 alcgr %r7,%r8 - alcgr %r6,zero - alg %r7,16(%r2,%r1) - stg %r7,16(%r2,%r1) + alcgr %r6,%r0 + mlgr %r8,%r5 + + alg %r7,0x10(%r2,%r1) + stg %r7,0x10(%r2,%r1) - lg %r9,24(%r2,%r3) - mlgr %r8,%r5 alcgr %r9,%r6 - alcgr %r8,zero - alg %r9,24(%r2,%r1) - stg %r9,24(%r2,%r1) + alcgr %r8,%r0 - la %r2,32(%r2) // i+=4 - brct %r4,.Loop4_madd + alg %r9,0x18(%r2,%r1) + stg %r9,0x18(%r2,%r1) + la %r2,0x20(%r0,%r2) // i+=4 + + brct %r4,.Loop4_madd la %r10,1(%r10) // see if len%4 is zero ... brct %r10,.Loop1_madd // without touching condition code:-) -- 1.8.3.1 _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sun Nov 8 11:37:57 2015 From: rt at openssl.org (Daniel Kahn Gillmor via RT) Date: Sun, 08 Nov 2015 11:37:57 +0000 Subject: [openssl-dev] [openssl.org #4129] [PATCH] Can BIO_new_mem_buf take a const void* instead of a void* ? In-Reply-To: <1446841060-15685-1-git-send-email-dkg@fifthhorseman.net> References: <1446841060-15685-1-git-send-email-dkg@fifthhorseman.net> Message-ID: The documentation asserts that BIO_new_mem_buf is forced to a read-only state ("The BIO is set to a read only state and as a result cannot be written to"), but it requires passing in a void*. This makes it hard to use from a function that has a const buffer. Presumably most code that tries to use a const buffer with BIO_new_mem_buf either casts away the constness (bad practice, since OpenSSL's API itself isn't guaranteeing it will actually remain const) or copies the memory to a non-const buffer before passing it in (an unnecessary memcpy). The changeset proposed here makes OpenSSL's API offer the guarantee that its documentation appears to make by casting away the constness internally to BIO_new_mem_buf, but i haven't analyzed all the possible ways that an arbitrary BIO can be (mis)used internally code to be sure this is safe. If this is not a safe thing to do, we should instead modify the documentation to avoid the implication that such a buffer will remain read-only. --- crypto/bio/bss_mem.c | 6 ++++-- doc/crypto/BIO_s_mem.pod | 2 +- include/openssl/bio.h | 2 +- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/crypto/bio/bss_mem.c b/crypto/bio/bss_mem.c index 485a8bf..e50db43 100644 --- a/crypto/bio/bss_mem.c +++ b/crypto/bio/bss_mem.c @@ -109,7 +109,7 @@ BIO_METHOD *BIO_s_secmem(void) return(&secmem_method); } -BIO *BIO_new_mem_buf(void *buf, int len) +BIO *BIO_new_mem_buf(const void *buf, int len) { BIO *ret; BUF_MEM *b; @@ -123,7 +123,9 @@ BIO *BIO_new_mem_buf(void *buf, int len) if ((ret = BIO_new(BIO_s_mem())) == NULL) return NULL; b = (BUF_MEM *)ret->ptr; - b->data = buf; + b->data = (void*) buf; /* is it safe to cast away constness here + and rely on the MEM_RDONLY flags set + below? */ b->length = sz; b->max = sz; ret->flags |= BIO_FLAGS_MEM_RDONLY; diff --git a/doc/crypto/BIO_s_mem.pod b/doc/crypto/BIO_s_mem.pod index 1aa7e6e..1fa62b5 100644 --- a/doc/crypto/BIO_s_mem.pod +++ b/doc/crypto/BIO_s_mem.pod @@ -17,7 +17,7 @@ BIO_get_mem_ptr, BIO_new_mem_buf - memory BIO BIO_set_mem_buf(BIO *b,BUF_MEM *bm,int c) BIO_get_mem_ptr(BIO *b,BUF_MEM **pp) - BIO *BIO_new_mem_buf(void *buf, int len); + BIO *BIO_new_mem_buf(const void *buf, int len); =head1 DESCRIPTION diff --git a/include/openssl/bio.h b/include/openssl/bio.h index f0fbc5b..c2be049 100644 --- a/include/openssl/bio.h +++ b/include/openssl/bio.h @@ -672,7 +672,7 @@ long BIO_debug_callback(BIO *bio, int cmd, const char *argp, int argi, BIO_METHOD *BIO_s_mem(void); BIO_METHOD *BIO_s_secmem(void); -BIO *BIO_new_mem_buf(void *buf, int len); +BIO *BIO_new_mem_buf(const void *buf, int len); BIO_METHOD *BIO_s_socket(void); BIO_METHOD *BIO_s_connect(void); BIO_METHOD *BIO_s_accept(void); -- 2.6.2 _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sun Nov 8 11:37:55 2015 From: rt at openssl.org (tamil.selvan@winfoware.com via RT) Date: Sun, 08 Nov 2015 11:37:55 +0000 Subject: [openssl-dev] [openssl.org #4125] Got Error In-Reply-To: <328820850.97013.1446702288123.JavaMail.yahoo@mail.yahoo.com> References: <328820850.97013.1446702288123.JavaMail.yahoo.ref@mail.yahoo.com> <328820850.97013.1446702288123.JavaMail.yahoo@mail.yahoo.com> Message-ID: Hi, I m getting this error : ?if you can solve this problem please reply to this mail. ? "_BIO_new_mem_buf", referenced from: ? "_PEM_read_bio_RSA_PUBKEY", referenced from: ? "_RSA_size", referenced from: ? "_RSA_public_encrypt", referenced from: ld: warning: ld: warning: ignoring file /Users/dvios-mac/Documents/Project/Collections/PaymentIntegation/openssl-1.0.1i-MacOSX/lib/libssl.a, missing required architecture arm64 in file /Users/dvios-mac/Documents/Project/Collections/PaymentIntegation/openssl-1.0.1i-MacOSX/lib/libssl.a (2 slices)ignoring file /Users/dvios-mac/Documents/Project/Collections/PaymentIntegation/openssl-1.0.1i-MacOSX/lib/libcrypto.a, missing required architecture arm64 in file /Users/dvios-mac/Documents/Project/Collections/PaymentIntegation/openssl-1.0.1i-MacOSX/lib/libcrypto.a (2 slices) clang: error: linker command failed with exit code 1 (use -v to see invocation) Regards TAMIL SELVANiOS DeveloperM.no : 8050961727Email :tamil.selvan at winfoware.com -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-11-05 at 10.06.43 am.png Type: image/png Size: 42993 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sun Nov 8 11:43:09 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Sun, 08 Nov 2015 11:43:09 +0000 Subject: [openssl-dev] [openssl.org #4124] Illegal instruction when using aes-ni-sha256 stitched implementation on AMD CPU In-Reply-To: <20151108114300.GA15358@roeckx.be> References: <1446731461.2626.27.camel@redhat.com> <20151108114300.GA15358@roeckx.be> Message-ID: On Sun, Nov 08, 2015 at 11:37:55AM +0000, Tomas Mraz via RT wrote: > The aes-ni-sha256 stitched implementation causes SIGILL on AMD A4-6210. > It is caused by not using the AVX+SSSE3 code path for non-Intel CPUs > although the CPU seems to be fully capable of running it. > > The ia32cap vector is 0x7ED8220B078BFFFF but when you set it explicitly > with OPENSSL_ia32cap=0x7ED8220B478BFFFF (i.e. the Intel CPU bit is set) > it works fine and the AVX+SSSE3 codepath is taken. > > See also https://bugzilla.redhat.com/show_bug.cgi?id=1278194 for > details. An other bug about this is: https://bugs.debian.org/793557 There is already a patch for this waiting review. Kurt From rt at openssl.org Mon Nov 9 08:15:26 2015 From: rt at openssl.org (David Woodhouse via RT) Date: Mon, 09 Nov 2015 08:15:26 +0000 Subject: [openssl-dev] [openssl.org #4130] [RFC] Provide enginesdir in pkgconfig file In-Reply-To: <1447055825.81031.20.camel@infradead.org> References: <1447055825.81031.20.camel@infradead.org> Message-ID: External engines such as engine_pkcs11 want to install into $ENGINESDIR. Would be nice if we could tell where it is by using $(pkg-config --variable=enginesdir openssl) It's theoretically possible to find it by defining HEADER_CRYPTLIB_H and then including opensslconf.h, although that's horrid enough even before you consider cross-compilation (i.e. you can't just use printf). Can we put it in openssl.pc please? (Of course, something as fundamental as engine_pkcs11 shouldn't be external anyway, but that's a different story...) -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Nov 9 14:41:50 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Mon, 09 Nov 2015 14:41:50 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <1583838.DggXAzmJpE@pintsize.usersys.redhat.com> References: <1583838.DggXAzmJpE@pintsize.usersys.redhat.com> Message-ID: Looks like rekeying is on the table again for TLSv1.3: https://www.ietf.org/mail-archive/web/tls/current/msg18295.html so I'd say this issue should get fixed or at least workarounded (allowed in case the identity doesn't change) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Mon Nov 9 16:46:24 2015 From: rt at openssl.org (Kaduk, Ben via RT) Date: Mon, 09 Nov 2015 16:46:24 +0000 Subject: [openssl-dev] [openssl.org #4125] Got Error In-Reply-To: <5640CDD5.6060804@akamai.com> References: <328820850.97013.1446702288123.JavaMail.yahoo.ref@mail.yahoo.com> <328820850.97013.1446702288123.JavaMail.yahoo@mail.yahoo.com> <5640CDD5.6060804@akamai.com> Message-ID: On 11/08/2015 05:37 AM, tamil.selvan at winfoware.com via RT wrote: > Hi, > I m getting this error : if you can solve this problem please reply to this mail. > "_BIO_new_mem_buf", referenced from: > "_PEM_read_bio_RSA_PUBKEY", referenced from: > "_RSA_size", referenced from: > "_RSA_public_encrypt", referenced from: > ld: warning: ld: warning: ignoring file /Users/dvios-mac/Documents/Project/Collections/PaymentIntegation/openssl-1.0.1i-MacOSX/lib/libssl.a, missing required architecture arm64 in file /Users/dvios-mac/Documents/Project/Collections/PaymentIntegation/openssl-1.0.1i-MacOSX/lib/libssl.a (2 slices)ignoring file /Users/dvios-mac/Documents/Project/Collections/PaymentIntegation/openssl-1.0.1i-MacOSX/lib/libcrypto.a, missing required architecture arm64 in file /Users/dvios-mac/Documents/Project/Collections/PaymentIntegation/openssl-1.0.1i-MacOSX/lib/libcrypto.a (2 slices) > You probably should show more of the build log, but the "missing required architecture arm64" is a big warning sign. Are you trying to build for arm64? What measures did you take to do so? -Ben Kaduk From rt at openssl.org Mon Nov 9 17:00:45 2015 From: rt at openssl.org (Kaduk, Ben via RT) Date: Mon, 09 Nov 2015 17:00:45 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <5640D134.3000305@akamai.com> References: <1583838.DggXAzmJpE@pintsize.usersys.redhat.com> <5640D134.3000305@akamai.com> Message-ID: On 11/09/2015 08:41 AM, Hubert Kario via RT wrote: > Looks like rekeying is on the table again for TLSv1.3: > https://www.ietf.org/mail-archive/web/tls/current/msg18295.html The proposed rekeying mechanism is not looking like renegotiation... > so I'd say this issue should get fixed or at least workarounded (allowed > in case the identity doesn't change) > ...so it's not at all clear that it bears any relevance to this ticket. -Ben From rt at openssl.org Mon Nov 9 17:06:02 2015 From: rt at openssl.org (Kaduk, Ben via RT) Date: Mon, 09 Nov 2015 17:06:02 +0000 Subject: [openssl-dev] [openssl.org #4123] Query regarding dummy variable inside crypto In-Reply-To: <5640D278.7040206@akamai.com> References: <5640D278.7040206@akamai.com> Message-ID: On 11/08/2015 05:37 AM, tosif tamboli via RT wrote: > Hi , > I am compiling crypto in openssl for vxWorks version 5.4 > with 5.5.1 it compiles well > But with 5.4 it gives error for below files > bn_depr.c > ccppc: Internal compiler error: program cc1 got fatal signal 6 > > When checked it gives error for location > static void *dummy=&dummy; > When I comment it then compiles well. but not getting why it's required if > it's not being used anywhere. > > Can you please provide your inputs for above? > It is present so that when OPENSSL_NO_DEPRECATED is set, pedantic compilers do not warn about an empty compilation unit. However, it does not conform to the current best practice for such code. The attached patch should help. -Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: pedantic.diff Type: text/x-patch Size: 986 bytes Desc: not available URL: From rt at openssl.org Mon Nov 9 19:39:49 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Mon, 09 Nov 2015 19:39:49 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <3533698.vtH8qC3ozs@pintsize.usersys.redhat.com> References: <5640D134.3000305@akamai.com> <3533698.vtH8qC3ozs@pintsize.usersys.redhat.com> Message-ID: On Monday 09 November 2015 17:00:45 Kaduk, Ben via RT wrote: > On 11/09/2015 08:41 AM, Hubert Kario via RT wrote: > > Looks like rekeying is on the table again for TLSv1.3: > > https://www.ietf.org/mail-archive/web/tls/current/msg18295.html > > The proposed rekeying mechanism is not looking like renegotiation... > > > so I'd say this issue should get fixed or at least workarounded > > (allowed in case the identity doesn't change) > > ...so it's not at all clear that it bears any relevance to this > ticket. it means that the postgres expectation for such functionality won't go away and its behaviour cannot be dismissed as "doing a silly thing" -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Mon Nov 9 19:43:28 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Mon, 09 Nov 2015 19:43:28 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <11050742.SAcpT9YNAe@pintsize.usersys.redhat.com> References: <1583838.DggXAzmJpE@pintsize.usersys.redhat.com> <11050742.SAcpT9YNAe@pintsize.usersys.redhat.com> Message-ID: On Monday 09 November 2015 14:41:50 Hubert Kario via RT wrote: > Looks like rekeying is on the table again for TLSv1.3: > https://www.ietf.org/mail-archive/web/tls/current/msg18295.html > > so I'd say this issue should get fixed or at least workarounded > (allowed in case the identity doesn't change) I probably should be more clear in that this is response for Matt's comment from 2015-10-16: > I think we should be marking this as a "won't fix" for all released > versions. The question is whether we should even attempt to fix it for > 1.1.0 or not. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Tue Nov 10 01:26:02 2015 From: rt at openssl.org (Adam Langley via RT) Date: Tue, 10 Nov 2015 01:26:02 +0000 Subject: [openssl-dev] [openssl.org #4131] Memory leak when parsing invalid X509_ATTRIBUTE In-Reply-To: References: Message-ID: The following code: EVP_PKEY_free(d2i_AutoPrivateKey(NULL, &bufp, n)); Will leak memory when fed this input: 30390201023009060138080469303080301901029ff88b298030b01b060922be0804e930864886f70d3a0180093080060102308030013b0200000420308204e930c3e8300105308030013b01040202ff003029021103292902009930800621022404e83001010430801b06092a86483001aa0286c030dfe980 I believe this is because the X509_ATTRIBUTE item "combines" the first and second members. Thus, after parsing an ASN1_OBJECT, the main loop in ASN1_item_ex_d2i does `pseqval = asn1_get_field_ptr(pval, seqtt);` with i=1 and gets pseqval=pval. ASN1_item_ex_d2i has code to "/* Free up and zero CHOICE value if initialised */", but it doesn't trigger in this situation and then ASN1_item_ex_d2i overwrites the ASN1_OBJECT pointer and leaks it. The trace of the leak is the following, from 1.0.1 HEAD: ==12959== 41 (40 direct, 1 indirect) bytes in 1 blocks are definitely lost in loss record 7 of 16 ==12959== at 0x40307C4: malloc (valgrind/coregrind/m_replacemalloc/vg_replace_malloc.c:270) ==12959== by 0x40AB43: default_malloc_ex (/agl/openssl/crypto/mem.c:79) ==12959== by 0x40B1D3: CRYPTO_malloc (/agl/openssl/crypto/mem.c:342) ==12959== by 0x432006: ASN1_OBJECT_new (/agl/openssl/crypto/asn1/a_object.c:346) ==12959== by 0x431E6E: c2i_ASN1_OBJECT (/agl/openssl/crypto/asn1/a_object.c:301) ==12959== by 0x4069D7: asn1_ex_c2i (/agl/openssl/crypto/asn1/tasn_dec.c:874) ==12959== by 0x40682A: asn1_d2i_ex_primitive (/agl/openssl/crypto/asn1/tasn_dec.c:831) ==12959== by 0x404F15: ASN1_item_ex_d2i (/agl/openssl/crypto/asn1/tasn_dec.c:207) ==12959== by 0x40632C: asn1_template_noexp_d2i (/agl/openssl/crypto/asn1/tasn_dec.c:691) ==12959== by 0x405F20: asn1_template_ex_d2i (/agl/openssl/crypto/asn1/tasn_dec.c:579) ==12959== by 0x4059DD: ASN1_item_ex_d2i (/agl/openssl/crypto/asn1/tasn_dec.c:443) ==12959== by 0x4061B6: asn1_template_noexp_d2i (/agl/openssl/crypto/asn1/tasn_dec.c:663) _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Tue Nov 10 10:03:17 2015 From: rt at openssl.org (tosif tamboli via RT) Date: Tue, 10 Nov 2015 10:03:17 +0000 Subject: [openssl-dev] [openssl.org #4123] Query regarding dummy variable inside crypto In-Reply-To: References: <5640D278.7040206@akamai.com> Message-ID: Thanks for your inputs On Mon, Nov 9, 2015 at 10:36 PM, Kaduk, Ben via RT wrote: > On 11/08/2015 05:37 AM, tosif tamboli via RT wrote: > > Hi , > > I am compiling crypto in openssl for vxWorks version 5.4 > > with 5.5.1 it compiles well > > But with 5.4 it gives error for below files > > bn_depr.c > > ccppc: Internal compiler error: program cc1 got fatal signal 6 > > > > When checked it gives error for location > > static void *dummy=&dummy; > > When I comment it then compiles well. but not getting why it's required > if > > it's not being used anywhere. > > > > Can you please provide your inputs for above? > > > > It is present so that when OPENSSL_NO_DEPRECATED is set, pedantic > compilers do not warn about an empty compilation unit. However, it does > not conform to the current best practice for such code. The attached > patch should help. > > -Ben > > From rt at openssl.org Tue Nov 10 15:25:54 2015 From: rt at openssl.org (Marcus Meissner via RT) Date: Tue, 10 Nov 2015 15:25:54 +0000 Subject: [openssl-dev] [openssl.org #4132] test/dsatest.c wrong argument to BIO_printf In-Reply-To: <20151110152542.GE18577@suse.de> References: <20151110152542.GE18577@suse.de> Message-ID: Hi, apply this patch ... commit c01f7e9e233e5e5dabd1ec01eb17198b0798e092 Author: Marcus Meissner Date: Tue Nov 10 16:24:51 2015 +0100 fixed wrong argument to BIO_printf diff --git a/test/dsatest.c b/test/dsatest.c index 1f4b837..fe25352 100644 --- a/test/dsatest.c +++ b/test/dsatest.c @@ -247,7 +247,7 @@ static int dsa_cb(int p, int n, BN_GENCB *arg) (void)BIO_flush(BN_GENCB_get_arg(arg)); if (!ok && (p == 0) && (num > 1)) { - BIO_printf((BIO *)arg, "error in dsatest\n"); + BIO_printf(BN_GENCB_get_arg(arg), "error in dsatest\n"); return 0; } return 1; _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From weber at infotech.de Tue Nov 10 17:03:22 2015 From: weber at infotech.de (weber at infotech.de) Date: Tue, 10 Nov 2015 18:03:22 +0100 Subject: [openssl-dev] certificate signing using rsa pss algorithm? Message-ID: <5642235A.4020500@infotech.de> Dear openssl developers, we are about to setup a new pki. So we have to choose the appropriate algorithms and parameters. How about certificates signed using rsa pcks#1v2.1 (aka pss) signed certificates? The latest known statement in this context we found is from Dr. Henson on May 8, 2014. He stated: ... > It is possible to add an "alias" for this algorithm and then OpenSSL can > handle the key directly. It wont however support the PSS semantics properly: > i.e. the key can only be used for PSS and any parameter restrictions. For that > reason this hasn't been done in the official sources. ... Is there any progress in adopting pss certificates consistently? Which difficulies do exist? The current German Algorithmenkatalog states, that security fitness for signatures using the rsa pkcs#1v1.5 padding ends at the end of 2016. Therefore, we are looking for proper algorithms whose security finess ist expected to last longer. Currently the only named alternative is ecdsa signatures, which should be thoroughly supported by current openssl versions. Thanks in advance -- Christian Weber From rt at openssl.org Tue Nov 10 21:33:44 2015 From: rt at openssl.org (Adam Langley via RT) Date: Tue, 10 Nov 2015 21:33:44 +0000 Subject: [openssl-dev] [openssl.org #4131] AutoReply: Memory leak when parsing invalid X509_ATTRIBUTE In-Reply-To: References: Message-ID: (Please note that credit for this goes to libFuzzer.) From dmitry at addlive.com Wed Nov 11 04:06:08 2015 From: dmitry at addlive.com (Dmitry Sobinov) Date: Wed, 11 Nov 2015 15:06:08 +1100 Subject: [openssl-dev] [BUG] Data races in lhash.c Message-ID: Got some reports from clang Thread Sanitizer about concurrent access to shared variables from _LHASH structure in crypto/lhash/lhash.c. Following members are written/read are not protected: error, num_hash_calls, num_hash_comps, num_comp_calls, num_retrieve. Can be reproduced by creating many SSL_CTX contexts in concurrent threads. One of the report from TSan: ================== WARNING: ThreadSanitizer: data race (pid=21810) Write of size 8 at 0x7d2c0000aff0 by thread T4: #0 getrn /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/lhash/lhash.c:408 (test_app+0x0000007f9ebb) #1 lh_retrieve /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/lhash/lhash.c:248 (test_app+0x0000007faa17) #2 OBJ_NAME_get /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/objects/o_names.c:167 (test_app+0x000000782a05) #3 EVP_get_digestbyname /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/evp/names.c:124 (test_app+0x00000081189d) #4 SSL_CTX_new /home/dmitry.sobinov/builds/openssl-1.0.2d/ssl/ssl_lib.c:1963 (test_app+0x00000074fe09) Previous write of size 8 at 0x7d2c0000aff0 by thread T8: #0 getrn /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/lhash/lhash.c:408 (test_app+0x0000007f9ebb) #1 lh_retrieve /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/lhash/lhash.c:248 (test_app+0x0000007faa17) #2 OBJ_NAME_get /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/objects/o_names.c:167 (test_app+0x000000782a05) #3 EVP_get_digestbyname /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/evp/names.c:124 (test_app+0x00000081189d) #4 SSL_CTX_new /home/dmitry.sobinov/builds/openssl-1.0.2d/ssl/ssl_lib.c:1963 (test_app+0x00000074fe09) Location is heap block of size 176 at 0x7d2c0000af50 allocated by main thread: #0 malloc (test_app+0x000000367c3d) #1 default_malloc_ex /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/mem.c:79 (test_app+0x00000077bce0) #2 CRYPTO_malloc /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/mem.c:342 (test_app+0x00000077cd33) #3 lh_new /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/lhash/lhash.c:120 (test_app+0x0000007f8864) #4 OBJ_NAME_init /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/objects/o_names.c:61 (test_app+0x0000007824a6) #5 OBJ_NAME_add /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/objects/o_names.c:185 (test_app+0x000000782b39) #6 EVP_add_cipher /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/evp/names.c:74 (test_app+0x00000081157d) #7 SSL_library_init /home/dmitry.sobinov/builds/openssl-1.0.2d/ssl/ssl_algs.c:68 (test_app+0x0000007749f0) #8 do_init /home/dmitry.sobinov/libs_tsan_cxx/include/boost/asio/ssl/detail/impl/openssl_init.ipp:39 (test_app+0x0000004000a4) #9 boost::asio::ssl::detail::openssl_init_base::instance() /home/dmitry.sobinov/libs_tsan_cxx/include/boost/asio/ssl/detail/impl/openssl_init.ipp:131 (test_app+0x0000003fffb0) #10 openssl_init /home/dmitry.sobinov/libs_tsan_cxx/include/boost/asio/ssl/detail/openssl_init.hpp:60 (test_app+0x0000003face9) #11 __cxx_global_var_init.25 /home/dmitry.sobinov/libs_tsan_cxx/include/boost/asio/ssl/detail/openssl_init.hpp:90 (test_app+0x0000003429c2) #12 __libc_csu_init (test_app+0x000000a9862c) --- Regards, Dmitry Sobinov -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Nov 11 04:15:16 2015 From: rt at openssl.org (Tino Lange via RT) Date: Wed, 11 Nov 2015 04:15:16 +0000 Subject: [openssl-dev] [openssl.org #4133] [patch] config does not detect Cygwin64 In-Reply-To: <5641C9B9.7080905@interactivedata.com> References: <5641C9B9.7080905@interactivedata.com> Message-ID: Hi! The following small patch for "config" detects Cygwin64 correctly and applies the already preconfigured flags for it via "Configure". > $ cat 03_cygwin64.patch > --- openssl-1.0.2d/config > +++ openssl-1.0.2d/config > @@ -353,7 +353,14 @@ > echo "${MACHINE}-whatever-cygwin_pre1.3" > ;; > *) > - echo "${MACHINE}-whatever-cygwin" > + case "$MACHINE" in > + x86_64) > + echo "${MACHINE}-whatever-cygwin64" > + ;; > + *) > + echo "${MACHINE}-whatever-cygwin" > + ;; > + esac > ;; > esac > exit 0 > @@ -853,6 +860,7 @@ > mips-sony-newsos4) OUT="newsos4-gcc" ;; > *-*-cygwin_pre1.3) OUT="Cygwin-pre1.3" ;; > *-*-cygwin) OUT="Cygwin" ;; > + *-*-cygwin64) OUT="Cygwin-x86_64" ;; > t3e-cray-unicosmk) OUT="cray-t3e" ;; > j90-cray-unicos) OUT="cray-j90" ;; > nsr-tandem-nsk) OUT="tandem-c89" ;; Cheers, Tino ******************************************************* This message (including any files transmitted with it) may contain confidential and/or proprietary information, is the property of Interactive Data Corporation and/or its subsidiaries, and is directed only to the addressee(s). If you are not the designated recipient or have reason to believe you received this message in error, please delete this message from your system and notify the sender immediately. An unintended recipient's disclosure, copying, distribution, or use of this message or any attachments is prohibited and may be unlawful. ******************************************************* _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Nov 11 04:15:16 2015 From: rt at openssl.org (=?UTF-8?B?0JPRgNC40LPQvtGA0LjQuSDQl9Cw0LPQvtC9?= via RT) Date: Wed, 11 Nov 2015 04:15:16 +0000 Subject: [openssl-dev] [openssl.org #4134] [BUG] Memory leak in STORE_store_private_key() In-Reply-To: References: Message-ID: Hello! I work with openssl 1.0.2d, and I found a memory leak in STORE_store_private_key() function (defined in crypto/store/str_lib.c). Here is a code fragment: 465:int STORE_store_private_key(STORE *s, EVP_PKEY *data, 466: OPENSSL_ITEM attributes[], 467: OPENSSL_ITEM parameters[]) 468:{ 469: STORE_OBJECT *object; 470: int i; 471: 472: check_store(s, STORE_F_STORE_STORE_PRIVATE_KEY, 473: store_object, STORE_R_NO_STORE_OBJECT_FUNCTION); 474: 475: object = STORE_OBJECT_new(); 476: if (!object) { 477: STOREerr(STORE_F_STORE_STORE_PRIVATE_KEY, ERR_R_MALLOC_FAILURE); 478: return 0; 479: } 480: object->data.key = EVP_PKEY_new(); 481: if (!object->data.key) { 482: STOREerr(STORE_F_STORE_STORE_PRIVATE_KEY, ERR_R_MALLOC_FAILURE); 483: return 0; 484: } 485: 486: CRYPTO_add(&data->references, 1, CRYPTO_LOCK_EVP_PKEY); 487:#ifdef REF_PRINT 488: REF_PRINT("EVP_PKEY", data); 489:#endif 490: object->data.key = data; At line 480 pointer to newly allocated key object is stored in 'object->data.key' variable. At line 490 variable 'object->data.key' is overwritten with new value. So, memory allocated at line 480 will never be freed. -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Nov 11 04:15:18 2015 From: rt at openssl.org (paul.dale@oracle.com via RT) Date: Wed, 11 Nov 2015 04:15:18 +0000 Subject: [openssl-dev] [openssl.org #4135] Fix for a multi-threading issue in policy cache creation In-Reply-To: <1942672.Q6Gmu0TQVo@acid> References: <1942672.Q6Gmu0TQVo@acid> Message-ID: Attached is a fix for a multi-threading issue in the policy cache creation code. Regards, Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- A non-text attachment was scrubbed... Name: threading.patch Type: text/x-patch Size: 955 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Nov 11 04:15:18 2015 From: rt at openssl.org (Dmitry Sobinov via RT) Date: Wed, 11 Nov 2015 04:15:18 +0000 Subject: [openssl-dev] [openssl.org #4136] [BUG] Data races in lhash.c In-Reply-To: References: Message-ID: Got some reports from clang Thread Sanitizer about concurrent access to shared variables from _LHASH structure in crypto/lhash/lhash.c. Following members are written/read are not protected: error, num_hash_calls, num_hash_comps, num_comp_calls, num_retrieve. Can be reproduced by creating many SSL_CTX contexts in concurrent threads. One of the report from TSan: ================== WARNING: ThreadSanitizer: data race (pid=21810) Write of size 8 at 0x7d2c0000aff0 by thread T4: #0 getrn /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/lhash/lhash.c:408 (test_app+0x0000007f9ebb) #1 lh_retrieve /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/lhash/lhash.c:248 (test_app+0x0000007faa17) #2 OBJ_NAME_get /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/objects/o_names.c:167 (test_app+0x000000782a05) #3 EVP_get_digestbyname /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/evp/names.c:124 (test_app+0x00000081189d) #4 SSL_CTX_new /home/dmitry.sobinov/builds/openssl-1.0.2d/ssl/ssl_lib.c:1963 (test_app+0x00000074fe09) Previous write of size 8 at 0x7d2c0000aff0 by thread T8: #0 getrn /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/lhash/lhash.c:408 (test_app+0x0000007f9ebb) #1 lh_retrieve /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/lhash/lhash.c:248 (test_app+0x0000007faa17) #2 OBJ_NAME_get /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/objects/o_names.c:167 (test_app+0x000000782a05) #3 EVP_get_digestbyname /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/evp/names.c:124 (test_app+0x00000081189d) #4 SSL_CTX_new /home/dmitry.sobinov/builds/openssl-1.0.2d/ssl/ssl_lib.c:1963 (test_app+0x00000074fe09) Location is heap block of size 176 at 0x7d2c0000af50 allocated by main thread: #0 malloc (test_app+0x000000367c3d) #1 default_malloc_ex /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/mem.c:79 (test_app+0x00000077bce0) #2 CRYPTO_malloc /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/mem.c:342 (test_app+0x00000077cd33) #3 lh_new /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/lhash/lhash.c:120 (test_app+0x0000007f8864) #4 OBJ_NAME_init /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/objects/o_names.c:61 (test_app+0x0000007824a6) #5 OBJ_NAME_add /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/objects/o_names.c:185 (test_app+0x000000782b39) #6 EVP_add_cipher /home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/evp/names.c:74 (test_app+0x00000081157d) #7 SSL_library_init /home/dmitry.sobinov/builds/openssl-1.0.2d/ssl/ssl_algs.c:68 (test_app+0x0000007749f0) #8 do_init /home/dmitry.sobinov/libs_tsan_cxx/include/boost/asio/ssl/detail/impl/openssl_init.ipp:39 (test_app+0x0000004000a4) #9 boost::asio::ssl::detail::openssl_init_base::instance() /home/dmitry.sobinov/libs_tsan_cxx/include/boost/asio/ssl/detail/impl/openssl_init.ipp:131 (test_app+0x0000003fffb0) #10 openssl_init /home/dmitry.sobinov/libs_tsan_cxx/include/boost/asio/ssl/detail/openssl_init.hpp:60 (test_app+0x0000003face9) #11 __cxx_global_var_init.25 /home/dmitry.sobinov/libs_tsan_cxx/include/boost/asio/ssl/detail/openssl_init.hpp:90 (test_app+0x0000003429c2) #12 __libc_csu_init (test_app+0x000000a9862c) --- Regards, Dmitry Sobinov -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Nov 11 04:19:49 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 11 Nov 2015 04:19:49 +0000 Subject: [openssl-dev] [openssl.org #4134] [BUG] Memory leak in STORE_store_private_key() In-Reply-To: References: Message-ID: STORE is an experimental API that isn't used in 1.0.2 (or any earlier series). For the next major version, the STORE API is being entirely rewritten. Please stay tuned. In the mean time, I'll simply close this ticket, Vid Ons, 11 Nov 2015 kl. 04.15.16, skrev gzagon74 at gmail.com: > Hello! > > I work with openssl 1.0.2d, and I found a memory leak in > STORE_store_private_key() function (defined in crypto/store/str_lib.c). > Here is a code fragment: > > 465:int STORE_store_private_key(STORE *s, EVP_PKEY *data, > 466: OPENSSL_ITEM attributes[], > 467: OPENSSL_ITEM parameters[]) > 468:{ > 469: STORE_OBJECT *object; > 470: int i; > 471: > 472: check_store(s, STORE_F_STORE_STORE_PRIVATE_KEY, > 473: store_object, STORE_R_NO_STORE_OBJECT_FUNCTION); > 474: > 475: object = STORE_OBJECT_new(); > 476: if (!object) { > 477: STOREerr(STORE_F_STORE_STORE_PRIVATE_KEY, ERR_R_MALLOC_FAILURE); > 478: return 0; > 479: } > 480: object->data.key = EVP_PKEY_new(); > 481: if (!object->data.key) { > 482: STOREerr(STORE_F_STORE_STORE_PRIVATE_KEY, ERR_R_MALLOC_FAILURE); > 483: return 0; > 484: } > 485: > 486: CRYPTO_add(&data->references, 1, CRYPTO_LOCK_EVP_PKEY); > 487:#ifdef REF_PRINT > 488: REF_PRINT("EVP_PKEY", data); > 489:#endif > 490: object->data.key = data; > > At line 480 pointer to newly allocated key object is stored in > 'object->data.key' variable. > At line 490 variable 'object->data.key' is overwritten with new value. So, > memory allocated at line 480 will never be freed. -- Richard Levitte levitte at openssl.org From rt at openssl.org Wed Nov 11 11:16:56 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Wed, 11 Nov 2015 11:16:56 +0000 Subject: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse() In-Reply-To: <20151111111641.GA29211@kronk.local> References: <20151031130526.GA11805@kronk.local> <20151031215017.GA2962@kronk.local> <20151111111641.GA29211@kronk.local> Message-ID: (sorry for the delay, but I've been travelling and moving) On Sat, Oct 31, 2015 at 11:01:22pm +0000, Brian Smith via RT wrote: > On Sat, Oct 31, 2015 at 11:50 AM, Alessandro Ghedini via RT > The point is to let the person building OPENSSL say "I want the build to > fail if there isn't a secure way to zero memory, because I'm expecting > there to always be one in my configuration." Alternatively, there could be > an OPENSSL_USE_MEMSET_S flag that says "always use memset_s and never > anything else." So, I added memset_s support guarded by the OPENSSL_USE_MEMSET_S ifdef, but it needs to be specified manually during configuration for now. Ideally it should be added to the configration of the platforms that support memset_s. I also added support for explicit_bzero() on OpenBSD. None of this has been tested though. However, the thing about OpenSSL's build system is that the asm implementations will *always* take priority, so you'll also need to specify "no-asm" or this whole thing won't be built. This is another reason for dropping the assembly implementations of OPENSSL_cleanse btw. Also, FTR, apparently SecureZeroMemory() doesn't work on the mingw version that Travis installs, so that's currently failing to build. > > > The primary purpose of the assembly language implementations is to > > reduce the > > > possibility that the C compiler will do the weird things that C > > compilers love > > > to do. > > > > According to the changelog and git log, the primary purpose of the asm > > implementations was to improve performance (see commit b2dba9b). Using the > > volatile pointer implementation would IMO make these optimizations useless, > > hence the proposal to drop them and make things simpler. > > > Sorry. Instead of "primary purpose" (which implies intent), I should have > said 'primary advantage". An assembly language implementation is more > likely to work than a C implementation because the C compiler generally > won't analyze externally-assembled code That's also valid for my implementation IMO. The whole point of "volatile" is to prevent the compiler from trying to guess the content of the variable and do weird things with it. In any case we still need to have support for the no-asm case where neither memset_s or SecureZeroMemory are present. And as explained above, having the asm functions prevents people from actually using the safer alternatives so I still think it'd be better to just drop them. In order to avoid having builds that silently optimize away OPENSSL_cleanse it'd be nice to have a test case to check for that. OpenBSD/LibreSSL have somthing along those lines [0], but it doesn't seem to work as expected (well, at least not with OpenSSL), so alternative ideas are welcome. In any case, I added another commit to my PR that removes the asm functions, but I left it as a separate commit so it can be easily dropped. Cheers [0] https://github.com/libressl-portable/openbsd/blob/master/src/regress/lib/libc/explicit_bzero/explicit_bzero.c From alessandro at ghedini.me Wed Nov 11 11:16:56 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Wed, 11 Nov 2015 11:16:56 +0000 Subject: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code In-Reply-To: <5634B559.1020401@openssl.com> References: <20151031122641.GA11750@kronk.local> <5634B559.1020401@openssl.com> Message-ID: <20151111111656.GB29211@kronk.local> On Sat, Oct 31, 2015 at 08:34:33am -0400, Steve Marquess wrote: > On 10/31/2015 08:26 AM, Alessandro Ghedini via RT wrote: > > Hi, > > > > I don't know what your intentions are with FIPS support in master, ... > > We would like to continue to provide a FIPS validated module for the 1.1 > (and subsequent) releases. Unfortunately the current module ("OpenSSL > FIPS Object Module 2.0") designed for compatibility with the 1.0 > releases won't be compatible with 1.1. That means we need to obtain a > new validation for a new module, an endeavor fraught with many > difficulties (none of them technical). > > I do expect the stars will align for that eventually, as they have for > the five previous open source based validations. In the interim, since > the FIPS module is shaped almost entirely by policy and metaphysical > considerations, we should not include any incomplete FIPS specific code > in 1.1 -- code that even if complete in some speculative sense would > also be unusable absent a matching FIPS 140-2 validation. So, does the above mean that my patch is not going to be merged? Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Wed Nov 11 11:52:56 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Wed, 11 Nov 2015 11:52:56 +0000 Subject: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse() In-Reply-To: <20151111115243.GA17975@roeckx.be> References: <20151031130526.GA11805@kronk.local> <20151111111641.GA29211@kronk.local> <20151111115243.GA17975@roeckx.be> Message-ID: On Wed, Nov 11, 2015 at 11:16:56AM +0000, Alessandro Ghedini via RT wrote: > > I also added support for explicit_bzero() on OpenBSD. An explicit_bzero() call is no better than whatever OPENSSL_cleanse() does, because it has exactly the same problems. So I don't think this is useful to do. > Also, FTR, apparently SecureZeroMemory() doesn't work on the mingw version that > Travis installs, so that's currently failing to build. SecureZeroMemory() (and memset_s()) must be supported by the compiler. I don't think any compiler other that Microsoft's one going to support SecureZeroMemory(). > That's also valid for my implementation IMO. The whole point of "volatile" is > to prevent the compiler from trying to guess the content of the variable and do > weird things with it. As far as I understand volatile will not prevent the compiler from removing the call. Volatile will only disable some optimizations, but it can still see that whatever is written isn't used anymore and so can be removed. The advantage of assembler is that the compiler doesn't know what the assembler does and that the call can have side effects other than writing to that buffer, preventing it from removing that call. That is, as Brian points out, as long as the compiler doesn't start to learn what the assembler does, which currently seems unlikely. > In order to avoid having builds that silently optimize away OPENSSL_cleanse > it'd be nice to have a test case to check for that. OpenBSD/LibreSSL have > somthing along those lines [0], but it doesn't seem to work as expected (well, > at least not with OpenSSL), so alternative ideas are welcome. As you point out, the compiler can be smart enough to optimize the call away. You should at least run that test uing LTO. Kurt From rt at openssl.org Wed Nov 11 12:37:56 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Wed, 11 Nov 2015 12:37:56 +0000 Subject: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse() In-Reply-To: <20151111123743.GA14189@kronk.local> References: <20151031130526.GA11805@kronk.local> <20151111111641.GA29211@kronk.local> <20151111115243.GA17975@roeckx.be> <20151111123743.GA14189@kronk.local> Message-ID: On Wed, Nov 11, 2015 at 11:52:56AM +0000, Kurt Roeckx via RT wrote: > On Wed, Nov 11, 2015 at 11:16:56AM +0000, Alessandro Ghedini via RT wrote: > > > > I also added support for explicit_bzero() on OpenBSD. > > An explicit_bzero() call is no better than whatever > OPENSSL_cleanse() does, because it has exactly the same problems. > So I don't think this is useful to do. Well, yeah, but OpenBSD sort of guarantees that explicit_bzero() is safe. In any case removing that is ok by me. > > Also, FTR, apparently SecureZeroMemory() doesn't work on the mingw version that > > Travis installs, so that's currently failing to build. > > SecureZeroMemory() (and memset_s()) must be supported by the > compiler. I don't think any compiler other that Microsoft's one > going to support SecureZeroMemory(). More recent versions of mingw do support SecureZeroMemory() so that's not the problem, it just so happens that the one installed by Travis is quite ancient. > > That's also valid for my implementation IMO. The whole point of "volatile" is > > to prevent the compiler from trying to guess the content of the variable and do > > weird things with it. > > As far as I understand volatile will not prevent the compiler from > removing the call. Volatile will only disable some optimizations, > but it can still see that whatever is written isn't used anymore and > so can be removed. No, when using the volatile pointer the compiler doesn't know if the target function is reentrant or not (because it doesn't know what the target function actually is) so removing the call is not safe, even by -O3 standards (e.g. that function might change a global variable or write to a file). Again, that's the whole point of "volatile". > > In order to avoid having builds that silently optimize away OPENSSL_cleanse > > it'd be nice to have a test case to check for that. OpenBSD/LibreSSL have > > somthing along those lines [0], but it doesn't seem to work as expected (well, > > at least not with OpenSSL), so alternative ideas are welcome. > > As you point out, the compiler can be smart enough to optimize the > call away. You should at least run that test uing LTO. Well, yeah, I've been doing my manual tests with LTO all along. My point was that on some platform/compiler/configuration, whatever implementation of OPENSSL_cleanse is used, it could still be optimized away. So it would be useful to have a test to detect that automatically when "make test" is run. However the test provided by OpenBSD/LibreSSL doesn't work, that is, with some configurations (e.g. when LTO is used) it doesn't actually detect that the call has been optimized away, so a smarter test is required, but I have no idea what that might look like. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Wed Nov 11 13:06:54 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Wed, 11 Nov 2015 13:06:54 +0000 Subject: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse() In-Reply-To: <20151111130642.GA19872@roeckx.be> References: <20151031130526.GA11805@kronk.local> <20151111115243.GA17975@roeckx.be> <20151111123743.GA14189@kronk.local> <20151111130642.GA19872@roeckx.be> Message-ID: On Wed, Nov 11, 2015 at 12:37:56PM +0000, Alessandro Ghedini via RT wrote: > On Wed, Nov 11, 2015 at 11:52:56AM +0000, Kurt Roeckx via RT wrote: > > On Wed, Nov 11, 2015 at 11:16:56AM +0000, Alessandro Ghedini via RT wrote: > > > Also, FTR, apparently SecureZeroMemory() doesn't work on the mingw version that > > > Travis installs, so that's currently failing to build. > > > > SecureZeroMemory() (and memset_s()) must be supported by the > > compiler. I don't think any compiler other that Microsoft's one > > going to support SecureZeroMemory(). > > More recent versions of mingw do support SecureZeroMemory() so that's not the > problem, it just so happens that the one installed by Travis is quite ancient. As far as I know mingw uses gcc so how is it able to guarantee that SecureZeroMemory() works as intended? > > > That's also valid for my implementation IMO. The whole point of "volatile" is > > > to prevent the compiler from trying to guess the content of the variable and do > > > weird things with it. > > > > As far as I understand volatile will not prevent the compiler from > > removing the call. Volatile will only disable some optimizations, > > but it can still see that whatever is written isn't used anymore and > > so can be removed. > > No, when using the volatile pointer the compiler doesn't know if the target > function is reentrant or not (because it doesn't know what the target function > actually is) so removing the call is not safe, even by -O3 standards (e.g. that > function might change a global variable or write to a file). Again, that's the > whole point of "volatile". So you're saying they assign the function that should be called to a volatile pointer, so the compiler can't be sure which function is called forcing it to read that volatile pointer all the time? I'm not sure the compiler isn't going to optimize that if it can tell nothing else is ever going to write that pointer. I think it's reasonable for it to assume that hardware isn't going to change that pointer. > > > In order to avoid having builds that silently optimize away OPENSSL_cleanse > > > it'd be nice to have a test case to check for that. OpenBSD/LibreSSL have > > > somthing along those lines [0], but it doesn't seem to work as expected (well, > > > at least not with OpenSSL), so alternative ideas are welcome. > > > > As you point out, the compiler can be smart enough to optimize the > > call away. You should at least run that test uing LTO. > > Well, yeah, I've been doing my manual tests with LTO all along. My point was > that on some platform/compiler/configuration, whatever implementation of > OPENSSL_cleanse is used, it could still be optimized away. So it would be > useful to have a test to detect that automatically when "make test" is run. Even the assembler version gets optimized away? Kurt From director at openca.org Wed Nov 11 16:27:15 2015 From: director at openca.org (Massimiliano Pala) Date: Wed, 11 Nov 2015 11:27:15 -0500 Subject: [openssl-dev] Fwd: [saag] Standard Crypto API + Symmetric Crypto At Rest In-Reply-To: <563DFCFB.8090405@openca.org> References: <563DFCFB.8090405@openca.org> Message-ID: <56436C63.6080302@openca.org> Hi OpenSSL Community, I originally posted this message on the security area ML at IETF and I am trying to reach out to a broad audience of experts, implementers, and vendors. I would love to have contributions and implementations (once we have some initial specs) around this initiative. I am still trying to find the right host for the mailing list where to discuss all aspects of this initiative, but I hope that this message will spark some interest and (especially from one of the most vibrant crypto library community out there) possibly inspire the community to join the envisioned effort. Any comments and feedback are welcome (positive and negative alike). Cheers, Max -------- Forwarded Message -------- Subject: [saag] Standard Crypto API + Symmetric Crypto At Rest Date: Sat, 7 Nov 2015 22:30:35 +0900 From: Massimiliano Pala Organization: OpenCA Labs To: saag at ietf.org Hi all, I am not sure this is the right place to write this e-mail, but I hope is. At the meeting I spoke with several people about an idea I had some time ago but never landed at IETF. Since I got positive feedback and suggestion to post the idea to this list to see if others might be interested, here's the summary e-mail. The idea is very simple: provide specifications for interfaces to cryptographic libraries. The basic idea is to provide an API that different vendors can implement on top of their libraries to provide a standard interface for applications. If successful, an application could make use of OpenSSL, MS-CAPI, Cryptlib, or any other crypto library that provides that interface without having to re-write the crypto-related code. This allows for portability (wider adoption of crypto-enabled applications), code/modules re-usability, and the possibility for applications to switch between vendors (e.g., switching to a better crypto library or dismissing a library that has shown vulnerabilities). Although I received positive feedback about the idea (I know, it has be attempted in the past.. ), I was never able to get the green light to proceed with a proposal for IETF (unfortunately the answer was always "we don't do APIs" ... which, actually, it is not true), so I decided to move forward anyway, since it is a real pain that needs to be solved. If the IETF will like to pick up the work in the future, great. If not, we'll solve the problem anyway :D If you are interested in participating in the effort (e.g., writing specs, participating in the discussion, provide feedback, or writing code) please contact me and we'll take it from there. I wrote a couple of pages today (very quick and dirty work for now.. so.. don't judge!), but I hope we'll be able to gather momentum and work together on this. The website is reachable at: http://cryptoapi.openca.org/ Last but not least - I am starting also another project that targets the use of SYMMETRIC crypto by providing support for encryption at rest. This library will provide support for storing encrypted data, signed (hmac) data, symmetric keys, and symmetric keys bundles (stack of keys) in such a way that it is simple to use (e.g., dealing with symmetric crypto is hard for the average developer since not much support, outside TLS, is provided). By defining a simple high-level API for symmetric crypto we want to fill the gap and, hopefully, increase the use of crypto also in those environment where asymmetric is not an option (e.g., latency constraints). The idea is to actually write a standard for symmetric crypto ... "at rest". Also for this project, please contact me directly (I still do not have pages for this project for various reasons - most importantly I still have to see if I get to open source what I did for my employer of if we have to start from scratch) at this e-mail address. Happy Security Everybody! Cheers, Max P.S.: Other items on the back burner that I would welcome contributions to are OCSP over DNS (ODIN), Lightweight Revocation Tokens (LIRT), the PKI Resource Query Protocol (PRQP), Simplified CMC over HTTP, and the Public Key (Discovery) System (PKS). -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Nov 11 17:15:06 2015 From: rt at openssl.org (Kaduk, Ben via RT) Date: Wed, 11 Nov 2015 17:15:06 +0000 Subject: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse() In-Reply-To: <56437790.7030501@akamai.com> References: <20151031130526.GA11805@kronk.local> <20151111123743.GA14189@kronk.local> <20151111130642.GA19872@roeckx.be> <56437790.7030501@akamai.com> Message-ID: On 11/11/2015 07:06 AM, Kurt Roeckx via RT wrote: > On Wed, Nov 11, 2015 at 12:37:56PM +0000, Alessandro Ghedini via RT wrote: >> On Wed, Nov 11, 2015 at 11:52:56AM +0000, Kurt Roeckx via RT wrote: >>> On Wed, Nov 11, 2015 at 11:16:56AM +0000, Alessandro Ghedini via RT wrote: >>>> Also, FTR, apparently SecureZeroMemory() doesn't work on the mingw version that >>>> Travis installs, so that's currently failing to build. >>> SecureZeroMemory() (and memset_s()) must be supported by the >>> compiler. I don't think any compiler other that Microsoft's one >>> going to support SecureZeroMemory(). >> More recent versions of mingw do support SecureZeroMemory() so that's not the >> problem, it just so happens that the one installed by Travis is quite ancient. > As far as I know mingw uses gcc so how is it able to guarantee > that SecureZeroMemory() works as intended? SecureZeroMemory is provided by the Windows system headers; its contract indicates that it will not be optimized out by compilers (it seems perform the writes through a volatile char*). > That's also valid for my implementation IMO. The whole point of "volatile" is > to prevent the compiler from trying to guess the content of the variable and do > weird things with it. >>> As far as I understand volatile will not prevent the compiler from >>> removing the call. Volatile will only disable some optimizations, >>> but it can still see that whatever is written isn't used anymore and >>> so can be removed. >> No, when using the volatile pointer the compiler doesn't know if the target >> function is reentrant or not (because it doesn't know what the target function >> actually is) so removing the call is not safe, even by -O3 standards (e.g. that >> function might change a global variable or write to a file). Again, that's the >> whole point of "volatile". > So you're saying they assign the function that should be called > to a volatile pointer, so the compiler can't be sure which > function is called forcing it to read that volatile pointer all > the time? > > I'm not sure the compiler isn't going to optimize that if it can > tell nothing else is ever going to write that pointer. I think > it's reasonable for it to assume that hardware isn't going to > change that pointer. > The contract of volatile means that the compiler is not permitted to assume that nothing else is going to write to that variable -- the compiler doesn't get to make the assumption about hardware not writing to the variable, even if we humans can. -Ben From rt at openssl.org Wed Nov 11 17:39:01 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Wed, 11 Nov 2015 17:39:01 +0000 Subject: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse() In-Reply-To: <20151111173857.GA12420@roeckx.be> References: <20151031130526.GA11805@kronk.local> <20151111130642.GA19872@roeckx.be> <56437790.7030501@akamai.com> <20151111173857.GA12420@roeckx.be> Message-ID: On Wed, Nov 11, 2015 at 05:15:06PM +0000, Kaduk, Ben via RT wrote: > On 11/11/2015 07:06 AM, Kurt Roeckx via RT wrote: > > On Wed, Nov 11, 2015 at 12:37:56PM +0000, Alessandro Ghedini via RT wrote: > >> On Wed, Nov 11, 2015 at 11:52:56AM +0000, Kurt Roeckx via RT wrote: > >>> On Wed, Nov 11, 2015 at 11:16:56AM +0000, Alessandro Ghedini via RT wrote: > >>>> Also, FTR, apparently SecureZeroMemory() doesn't work on the mingw version that > >>>> Travis installs, so that's currently failing to build. > >>> SecureZeroMemory() (and memset_s()) must be supported by the > >>> compiler. I don't think any compiler other that Microsoft's one > >>> going to support SecureZeroMemory(). > >> More recent versions of mingw do support SecureZeroMemory() so that's not the > >> problem, it just so happens that the one installed by Travis is quite ancient. > > As far as I know mingw uses gcc so how is it able to guarantee > > that SecureZeroMemory() works as intended? > > SecureZeroMemory is provided by the Windows system headers; its contract > indicates that it will not be optimized out by compilers (it seems > perform the writes through a volatile char*). That seems to be problematic, I think it has already be pointed out that some compilers actually do optimize that away. Volatile prevents caching, it does not prevent dead code elimination. > > That's also valid for my implementation IMO. The whole point of "volatile" is > > to prevent the compiler from trying to guess the content of the variable and do > > weird things with it. > >>> As far as I understand volatile will not prevent the compiler from > >>> removing the call. Volatile will only disable some optimizations, > >>> but it can still see that whatever is written isn't used anymore and > >>> so can be removed. > >> No, when using the volatile pointer the compiler doesn't know if the target > >> function is reentrant or not (because it doesn't know what the target function > >> actually is) so removing the call is not safe, even by -O3 standards (e.g. that > >> function might change a global variable or write to a file). Again, that's the > >> whole point of "volatile". > > So you're saying they assign the function that should be called > > to a volatile pointer, so the compiler can't be sure which > > function is called forcing it to read that volatile pointer all > > the time? > > > > I'm not sure the compiler isn't going to optimize that if it can > > tell nothing else is ever going to write that pointer. I think > > it's reasonable for it to assume that hardware isn't going to > > change that pointer. > > > The contract of volatile means that the compiler is not permitted to > assume that nothing else is going to write to that variable -- the > compiler doesn't get to make the assumption about hardware not writing > to the variable, even if we humans can. The contract of volatile means that the compiler can't cache it. But I think that's only when it actually generates code for it, not when it can optimize it away. Kurt From rt at openssl.org Wed Nov 11 18:23:31 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Wed, 11 Nov 2015 18:23:31 +0000 Subject: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse() In-Reply-To: <20151111182319.GA18180@kronk.local> References: <20151031130526.GA11805@kronk.local> <20151111123743.GA14189@kronk.local> <20151111130642.GA19872@roeckx.be> <20151111182319.GA18180@kronk.local> Message-ID: On Wed, Nov 11, 2015 at 01:06:54PM +0000, Kurt Roeckx via RT wrote: > On Wed, Nov 11, 2015 at 12:37:56PM +0000, Alessandro Ghedini via RT wrote: > > On Wed, Nov 11, 2015 at 11:52:56AM +0000, Kurt Roeckx via RT wrote: > > > On Wed, Nov 11, 2015 at 11:16:56AM +0000, Alessandro Ghedini via RT wrote: > > > > In order to avoid having builds that silently optimize away OPENSSL_cleanse > > > > it'd be nice to have a test case to check for that. OpenBSD/LibreSSL have > > > > somthing along those lines [0], but it doesn't seem to work as expected (well, > > > > at least not with OpenSSL), so alternative ideas are welcome. > > > > > > As you point out, the compiler can be smart enough to optimize the > > > call away. You should at least run that test uing LTO. > > > > Well, yeah, I've been doing my manual tests with LTO all along. My point was > > that on some platform/compiler/configuration, whatever implementation of > > OPENSSL_cleanse is used, it could still be optimized away. So it would be > > useful to have a test to detect that automatically when "make test" is run. > > Even the assembler version gets optimized away? Sorry, I didn't explain myself very well. What I tried was implement an obviously unsafe OPENSSL_cleanse (using just memset()) and then check if the LibreSSL test correctly caught the fact that the call was optimized away. The test worked in most scenarios, except when building with LTO. So it was only the test that didn't behave correctly. Cheers From rt at openssl.org Thu Nov 12 09:37:35 2015 From: rt at openssl.org (=?UTF-8?B?RmzDoXZpbyBNZWRlaXJvcw==?= via RT) Date: Thu, 12 Nov 2015 09:37:35 +0000 Subject: [openssl-dev] [openssl.org #4137] [PATCH] In-Reply-To: References: Message-ID: Hello OpenSSL contributors, A few week ago I submitted a patch to remove from the source code preprocessor conditional directives that split up parts of statements (#465 ). Some developers asked me and suggested some changes. I'm submitting a new pull request (#468 ) with the goal of removing all conditional directives of the following pattern: *#ifdef A* *if* (condition_1) *#else* *if* (condition_2) *#endif* { // code } I have used a tool that searches for this pattern and I have refactored them manually. We are able to detect other patterns of conditional directives that split up parts of statements to refactor manually (if it contributes to OpenSSL). Let me know if there are other patterns that are important to refactor in order to improve code understanding and so on. I'm willing to contribute. Best regards, Fl?vio Medeiros -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Nov 12 09:38:06 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Thu, 12 Nov 2015 09:38:06 +0000 Subject: [openssl-dev] [openssl.org #4138] Detection of assembler version In-Reply-To: <20151111175820.GA14677@roeckx.be> References: <20151111175820.GA14677@roeckx.be> Message-ID: Hi, I just found out that building with at least with the French locale the AVX code is missing. The problem is this code in crypto/sha/asm/sha1-x86_64.pl: if (`$ENV{CC} -Wa,-v -c -o /dev/null -x assembler /dev/null 2>&1` =~ /GNU assembler version ([2-9]\.[0-9]+)/) { $avx = ($1>=2.19) + ($1>=2.22); } In English it returns: GNU assembler version 2.25.1 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.25.1 But in French it returns: Version de l'assembleur GNU 2.25.1 (x86_64-linux-gnu) utilisant la version BFD (GNU Binutils for Debian) 2.25.1 A quick grep at least shows 17 affected files. The fix should be easy setting the locale to C when doing that check. Kurt _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From Stefan.Neis at t-online.de Thu Nov 12 17:45:43 2015 From: Stefan.Neis at t-online.de (Stefan.Neis at t-online.de) Date: Thu, 12 Nov 2015 18:45:43 +0100 (MET) Subject: [openssl-dev] certificate signing using rsa pss algorithm? In-Reply-To: <5642235A.4020500@infotech.de> References: <5642235A.4020500@infotech.de> Message-ID: <1447350343896.514603.f5a18b4fe531dff171f3dbb8d59cc7bb16f7f803@spica.telekom.de> Hi, You might want to upgrade to OpenSSL-1.0.2 which seems to support the RSA PSS algorithm, see https://openssl.org/news/changelog.html#x5. Regards, Stefan From jyothi.v at freescale.com Thu Nov 12 18:21:41 2015 From: jyothi.v at freescale.com (Vemulapalli Jyothi) Date: Thu, 12 Nov 2015 18:21:41 +0000 Subject: [openssl-dev] procedure for adding new engine registration Message-ID: Hi all, We would like to add a new engine registration to openssl. Can you please explain a procedure? When we gone through the code, we could find an engines directory in openssl , but those files are not getting compiled. Do we need to give some additional options. Can you please help. Thanks Jyothi -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Thu Nov 12 21:20:59 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 12 Nov 2015 21:20:59 +0000 Subject: [openssl-dev] [openssl.org #4138] Detection of assembler version In-Reply-To: <564502B8.7080901@openssl.org> References: <20151111175820.GA14677@roeckx.be> <564502B8.7080901@openssl.org> Message-ID: Hi, > I just found out that building with at least with the French > locale the AVX code is missing. The problem is this code in > crypto/sha/asm/sha1-x86_64.pl: > if (`$ENV{CC} -Wa,-v -c -o /dev/null -x assembler /dev/null 2>&1` > =~ /GNU assembler version ([2-9]\.[0-9]+)/) { > $avx = ($1>=2.19) + ($1>=2.22); > } > > In English it returns: > GNU assembler version 2.25.1 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.25.1 > > But in French it returns: > Version de l'assembleur GNU 2.25.1 (x86_64-linux-gnu) utilisant la version BFD (GNU Binutils for Debian) 2.25.1 > > A quick grep at least shows 17 affected files. > > The fix should be easy setting the locale to C when doing that > check. Oh! Though I'd like to suggest taking it even further. Namely setting LANG to C in top-most Makefile. This way we would also ensure that even compiler error messages are readable when reported. What do you think? (I wish one could do something like that even with Microsouple l'compilateur ;-) From matt at openssl.org Fri Nov 13 09:54:41 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 13 Nov 2015 09:54:41 +0000 Subject: [openssl-dev] procedure for adding new engine registration In-Reply-To: References: Message-ID: <5645B361.7040908@openssl.org> On 12/11/15 18:21, Vemulapalli Jyothi wrote: > Hi all, > > > > We would like to add a new engine registration to openssl. > > > > Can you please explain a procedure? > > > > When we gone through the code, we could find an engines directory in > openssl , but those files are not getting compiled. > > Do we need to give some additional options. Can you please help. Its not clear to me whether your asking "how do I create my own engine for my own purposes?" or "how do I create an engine that I want to get incorporated into the OpenSSL source and be distributed as part of OpenSSL?". The answers to these two questions are slightly different. For the former question I suggest you start with these two links: https://www.openssl.org/blog/blog/2015/10/07/engine-school/ https://www.openssl.org/blog/blog/2015/10/08/engine-building-lesson-1-a-minimum-useless-engine/ There's also some content on the wiki on this topic: https://wiki.openssl.org/index.php/Creating_an_OpenSSL_Engine_to_use_indigenous_ECDH_ECDSA_and_HASH_Algorithms For the latter question the technical procedure is essentially the same as above. However I am personally not keen on the introduction of new engines that do not have a broad applicability to large groups of users. That would typically rule out the introduction of manufacturer specific engines requiring the presence of additional hardware. Matt From jyothi.v at freescale.com Fri Nov 13 11:16:55 2015 From: jyothi.v at freescale.com (Vemulapalli Jyothi) Date: Fri, 13 Nov 2015 11:16:55 +0000 Subject: [openssl-dev] procedure for adding new engine registration In-Reply-To: <5645B361.7040908@openssl.org> References: <5645B361.7040908@openssl.org> Message-ID: Hi Matt, Very useful information. I too agree with you that we need not have a new engine distribution. I see some options like dynamic engines and static engine support. If we have built a library with dynamic engine interface, how can we do speed test using openssl speed command. Thanks Jyothi -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Friday, November 13, 2015 3:25 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] procedure for adding new engine registration On 12/11/15 18:21, Vemulapalli Jyothi wrote: > Hi all, > > > > We would like to add a new engine registration to openssl. > > > > Can you please explain a procedure? > > > > When we gone through the code, we could find an engines directory in > openssl , but those files are not getting compiled. > > Do we need to give some additional options. Can you please help. Its not clear to me whether your asking "how do I create my own engine for my own purposes?" or "how do I create an engine that I want to get incorporated into the OpenSSL source and be distributed as part of OpenSSL?". The answers to these two questions are slightly different. For the former question I suggest you start with these two links: https://www.openssl.org/blog/blog/2015/10/07/engine-school/ https://www.openssl.org/blog/blog/2015/10/08/engine-building-lesson-1-a-minimum-useless-engine/ There's also some content on the wiki on this topic: https://wiki.openssl.org/index.php/Creating_an_OpenSSL_Engine_to_use_indigenous_ECDH_ECDSA_and_HASH_Algorithms For the latter question the technical procedure is essentially the same as above. However I am personally not keen on the introduction of new engines that do not have a broad applicability to large groups of users. That would typically rule out the introduction of manufacturer specific engines requiring the presence of additional hardware. Matt _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From matt at openssl.org Fri Nov 13 11:43:41 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 13 Nov 2015 11:43:41 +0000 Subject: [openssl-dev] procedure for adding new engine registration In-Reply-To: References: <5645B361.7040908@openssl.org> Message-ID: <5645CCED.2000804@openssl.org> On 13/11/15 11:16, Vemulapalli Jyothi wrote: > Hi Matt, > > Very useful information. > > I too agree with you that we need not have a new engine distribution. > > I see some options like dynamic engines and static engine support. > > If we have built a library with dynamic engine interface, how can we do speed test using openssl speed command. As follows (on Linux): OPENSSL_ENGINES=/path/to/my/engine/dir openssl speed -engine myengine Matt From rt at openssl.org Fri Nov 13 12:50:59 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Fri, 13 Nov 2015 12:50:59 +0000 Subject: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse() In-Reply-To: <5645DCAE.6090102@openssl.org> References: <20151031130526.GA11805@kronk.local> <56437790.7030501@akamai.com> <20151111173857.GA12420@roeckx.be> <5645DCAE.6090102@openssl.org> Message-ID: > The contract of volatile means that the compiler can't cache it. > But I think that's only when it actually generates code for it, > not when it can optimize it away. Well, if that was the case, then you wouldn't be able to talk to hardware from C. Formally volatile references are not subject to away-optimization under no circumstances. Just like call to say fwrite(3) isn't. Or maybe write(2) would make even more illustrative example, because in fwrite case you have FILE * that is not declared const, so you can argue that compiler assumes that FILE object is modified. Well, it is, but that's not the reason for why compiler would never optimize away call to fwrite, isn't it? They may not be optimized away because opaque function calls, just like references to volatile object[!], are specified as *side effects*. Or in other words if reference to volatile object is optimized away, then it would be violation of standard and would have to be treated as compiler bug. And exactly this last thing was the original concern. Is there anything one can do to eliminate the *room* itself for compiler to screw things up? That's what assembly OPENSSL_cleanse was and still is about. Couple of points in overall context. As for zeroing memory vs. filling with non-zero. Swap argument doesn't really apply, because if memory was swapped at some point, swapped copy can persist even after original's modification. Even more likely so if you cleanse just before terminating application. In other words if you are set to secure swap file, then cleansing memory is not really the solution. As for LTO. I argue that LTO and even over-aggressive IPA doesn't belong in OpenSSL. Remember the week when UltraSPARC held SPEC benchmark record? Well, I don't expect you to remember the week (I actually don't), but rather how did it happen. Compiler decomposed array of structures to multiple arrays of elements comprising the structure and thus dramatically improved cache locality. With this in mind ask yourself if you would appreciate if side channel attack countermeasure falls victim to similar optimization? One can refer to what others are doing, but you would also have to recognize that others are consciously limiting their scope and kind of say "we make it work exactly where we are at the moment." I'm not saying that it's not viable strategy, only that it doesn't have to be universal. From emilia at openssl.org Fri Nov 13 13:40:33 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Fri, 13 Nov 2015 14:40:33 +0100 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback Message-ID: Hi all, We are considering removing from OpenSSL 1.1 known broken or outdated cryptographic primitives. As you may know the forks have already done this but I'd like to seek careful feedback for OpenSSL first to ensure we won't be breaking any major applications. These algorithms are currently candidates for removal: CAST IDEA MDC2 MD2 [ already disabled by default ] RC5 [ already disabled by default ] RIPEMD SEED WHIRLPOOL ALL BINARY ELLIPTIC CURVES My preference would be to remove these algorithms completely (as in, delete the code). Disabled-by-default code will either be re-enabled by distros (if there's widespread need for it - in which case we might as well leave it in) or will be poorly tested and is likely to just silently rot and break. This code is bloat and maintentance burden for us - my hope is that much of this code is effectively dead and can be removed. *Are you aware of any mainstream need to continue supporting these algorithms in OpenSSL 1.1?* Note that an older OpenSSL library or binary, or a standalone implementation or another crypto toolkit can always be used to continue supporting a legacy standalone application, or to decrypt ciphertext from the distant past. I am looking for use cases that could cause e.g. interop breakage between new and old peers, or major pain to distro end-users. These algorithms are obsolete but removing them doesn't look feasible: BLOWFISH - probably still in use though I don't know where exactly? MD4 - used in NTLM RC2 - used in PKCS#12 *Did I miss anything from the list?* Cheers, Emilia -------------- next part -------------- An HTML attachment was scrubbed... URL: From rainer.jung at kippdata.de Fri Nov 13 14:52:49 2015 From: rainer.jung at kippdata.de (Rainer Jung) Date: Fri, 13 Nov 2015 15:52:49 +0100 Subject: [openssl-dev] [openssl.org #4138] Detection of assembler version In-Reply-To: References: <20151111175820.GA14677@roeckx.be> <564502B8.7080901@openssl.org> Message-ID: <5645F941.7000806@kippdata.de> Am 12.11.2015 um 22:20 schrieb Andy Polyakov via RT: > Hi, > >> I just found out that building with at least with the French >> locale the AVX code is missing. The problem is this code in >> crypto/sha/asm/sha1-x86_64.pl: >> if (`$ENV{CC} -Wa,-v -c -o /dev/null -x assembler /dev/null 2>&1` >> =~ /GNU assembler version ([2-9]\.[0-9]+)/) { >> $avx = ($1>=2.19) + ($1>=2.22); >> } >> >> In English it returns: >> GNU assembler version 2.25.1 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.25.1 >> >> But in French it returns: >> Version de l'assembleur GNU 2.25.1 (x86_64-linux-gnu) utilisant la version BFD (GNU Binutils for Debian) 2.25.1 >> >> A quick grep at least shows 17 affected files. >> >> The fix should be easy setting the locale to C when doing that >> check. > > Oh! Though I'd like to suggest taking it even further. Namely setting > LANG to C in top-most Makefile. This way we would also ensure that even > compiler error messages are readable when reported. What do you think? > > (I wish one could do something like that even with Microsouple > l'compilateur ;-) Just a small addition: LANG gets overwritten by LC_* and LC_* gets overwritten by LC_ALL. So it would be strongest to set LC_ALL, not LANG. Regards, Rainer From rt at openssl.org Fri Nov 13 14:59:55 2015 From: rt at openssl.org (Rainer Jung via RT) Date: Fri, 13 Nov 2015 14:59:55 +0000 Subject: [openssl-dev] [openssl.org #4138] Detection of assembler version In-Reply-To: <5645F941.7000806@kippdata.de> References: <20151111175820.GA14677@roeckx.be> <564502B8.7080901@openssl.org> <5645F941.7000806@kippdata.de> Message-ID: Am 12.11.2015 um 22:20 schrieb Andy Polyakov via RT: > Hi, > >> I just found out that building with at least with the French >> locale the AVX code is missing. The problem is this code in >> crypto/sha/asm/sha1-x86_64.pl: >> if (`$ENV{CC} -Wa,-v -c -o /dev/null -x assembler /dev/null 2>&1` >> =~ /GNU assembler version ([2-9]\.[0-9]+)/) { >> $avx = ($1>=2.19) + ($1>=2.22); >> } >> >> In English it returns: >> GNU assembler version 2.25.1 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.25.1 >> >> But in French it returns: >> Version de l'assembleur GNU 2.25.1 (x86_64-linux-gnu) utilisant la version BFD (GNU Binutils for Debian) 2.25.1 >> >> A quick grep at least shows 17 affected files. >> >> The fix should be easy setting the locale to C when doing that >> check. > > Oh! Though I'd like to suggest taking it even further. Namely setting > LANG to C in top-most Makefile. This way we would also ensure that even > compiler error messages are readable when reported. What do you think? > > (I wish one could do something like that even with Microsouple > l'compilateur ;-) Just a small addition: LANG gets overwritten by LC_* and LC_* gets overwritten by LC_ALL. So it would be strongest to set LC_ALL, not LANG. Regards, Rainer From rt at openssl.org Fri Nov 13 16:19:03 2015 From: rt at openssl.org (Daniel Stenberg via RT) Date: Fri, 13 Nov 2015 16:19:03 +0000 Subject: [openssl-dev] [openssl.org #4139] bug: lacking OPENSSL_load_builtin_modules() docs In-Reply-To: References: Message-ID: Hey The man page for the function OPENSSL_load_builtin_modules() doesn't include any details on how the memory it allocates is supposed to get freed by a user. I assume CONF_modules_free() is the funtion to use for this purpose? -- / daniel.haxx.se _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rsalz at akamai.com Fri Nov 13 16:30:01 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 13 Nov 2015 16:30:01 +0000 Subject: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code In-Reply-To: <20151111111656.GB29211@kronk.local> References: <20151031122641.GA11750@kronk.local> <5634B559.1020401@openssl.com>,<20151111111656.GB29211@kronk.local> Message-ID: <1447432201088.88213@akamai.com> > So, does the above mean that my patch is not going to be merged? No. It will be. From bkaduk at akamai.com Fri Nov 13 17:00:54 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 13 Nov 2015 11:00:54 -0600 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <56460267.1080802@wisemo.com> References: <56460267.1080802@wisemo.com> Message-ID: <56461746.7040808@akamai.com> On 11/13/2015 09:31 AM, Jakob Bohm wrote: > On 13/11/2015 14:40, Emilia K?sper wrote: >> Hi all, >> >> We are considering removing from OpenSSL 1.1 known broken or outdated >> cryptographic primitives. As you may know the forks have already done >> this but I'd like to seek careful feedback for OpenSSL first to >> ensure we won't be breaking any major applications. >> >> These algorithms are currently candidates for removal: >> >> CAST >> IDEA >> MDC2 >> MD2 [ already disabled by default ] >> RC5 [ already disabled by default ] >> RIPEMD >> SEED >> WHIRLPOOL >> ALL BINARY ELLIPTIC CURVES >> I wonder why single-DES is not in the above list. (Maybe because no one has spoken up as being interested in disentangling triple-DES from single-DES?) >> My preference would be to remove these algorithms completely (as in, >> delete the code). Disabled-by-default code will either be re-enabled >> by distros (if there's widespread need for it - in which case we >> might as well leave it in) or will be poorly tested and is likely to >> just silently rot and break. This code is bloat and maintentance >> burden for us - my hope is that much of this code is effectively dead >> and can be removed. >> My hope as well :) >> These algorithms are obsolete but removing them doesn't look feasible: >> >> BLOWFISH - probably still in use though I don't know where exactly? >> MD4 - used in NTLM >> RC2 - used in PKCS#12 >> As another thread calls to mind, PKCS#12 could potentially just use triple-DES. (BTW, the CMS tests fail when openssl is configured with no-rc2, due to this; I have a WIP patch sitting around.) > MD2 is still present in the self-signature on some major > root certificates that are still trusted in signatures > on old/historic data and documents. Note that the > default OpenSSL code currently skips checking the > self-signature on self-signed root certificates, but > that was done based as a workaround for the disabling > of MD2, and is based on the (unreliable) assumption > that checking their internal consistency had no value > in determining the trust. Accepting MD2 only for this > limited role (and thus keeping the code around for that > case only) would be more secure. > I am not sure that I agree with the claim that this assumption is unreliable. There have been some (heated) discussions on the IETF tls WG list recently regarding the self-signatures on trust anchors, and I have not seen any compelling arguments there for checking the self-signature. The trust anchor is just a key and an identifier; its presence in the trust store seems necessary and sufficient to me. > The use of MD4 in NTLM is closely related to its use in > the password database format of computers that > interoperate with NTLM, SMB, CIFS, Microsoft Kerberos > extensions etc. Those password databases and related > protocols will probably outlive NTLM itself by many > years. > The MD4 in the NTLM password hash is unsalted, for extra insecurity. The only real reason to still be using MD4 (by way of the RC4 enctype) in Kerberos is if you need to interoperate with WinXP or Server 2003 machines, but those are not really supported anymore. We are working to get RC4 explicitly deprecated for Kerberos at the IETF. -Ben Kaduk -------------- next part -------------- An HTML attachment was scrubbed... URL: From swall at redcom.com Fri Nov 13 17:05:11 2015 From: swall at redcom.com (Wall, Stephen) Date: Fri, 13 Nov 2015 12:05:11 -0500 Subject: [openssl-dev] OCSP integration into TLS handshake Message-ID: <401084E5E73F4241A44F3C9E6FD79428011DFE5B02@exch-01> Has there been/will there be any development towards integrating OCSP checking into the handshake the way CRL checking is, along the lines of Alexander Komyagin's patch from 2012? https://marc.info/?l=openssl-dev&m=133994624016769&w=2 https://marc.info/?l=openssl-users&m=134035740600560&w=2 This would be very useful for easily getting OCSP checking into applications that do not currently support it. -Steve Wall From Stefan.Neis at t-online.de Fri Nov 13 17:08:04 2015 From: Stefan.Neis at t-online.de (Stefan.Neis at t-online.de) Date: Fri, 13 Nov 2015 18:08:04 +0100 (MET) Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: Message-ID: <1447434484727.167123.bfa0e6052041fbef094cd397c7d2af1a0f777f4c@spica.telekom.de> Hi, > We are considering removing from OpenSSL 1.1 known broken > or outdated cryptographic primitives. As you may know the forks > have already done this but I'd like to seek careful feedback for > OpenSSL first to ensure we won't be breaking any major applications. [...] > My preference would be to remove these algorithms completely > (as in, delete the code). >From the formal[istic] point of view, I'd suggest to follow the way many libraries use for API changes, i.e. to only remove the algorithms that currently are already disabled by default and only disable the rest (clearly stating the intention of removing them in the next release), but still keep if for now. So users get a fair warning and a timeframe for "fixes", before things are finally removed. OTOH, crypto algorithms aren't like "normal APIs", so a wake-up call saying "if you still use those outdated algorithms, fix it _now_" (as it's no longer supported) might even be a good thing... > Did I miss anything from the list? Since you mentioned RC2 and RC5, what about the "officially deprecated" RC4? (although it seems "less outdated" than some of the others...). Maybe at least have an option to disable it? Regards, Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jifl at eCosCentric.com Fri Nov 13 18:03:33 2015 From: jifl at eCosCentric.com (Jonathan Larmour) Date: Fri, 13 Nov 2015 18:03:33 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <1447434484727.167123.bfa0e6052041fbef094cd397c7d2af1a0f777f4c@spica.telekom.de> References: <1447434484727.167123.bfa0e6052041fbef094cd397c7d2af1a0f777f4c@spica.telekom.de> Message-ID: <564625F5.1050703@eCosCentric.com> Hi, On 13/11/15 17:08, Stefan.Neis at t-online.de wrote: >> We are considering removing from OpenSSL 1.1 known broken >> or outdated cryptographic primitives. > [...] >> My preference would be to remove these algorithms completely >> (as in, delete the code). > > From the formal[istic] point of view, I'd suggest to follow the way > many libraries use for API changes, i.e. to only remove the > algorithms that currently are already disabled by default and only > disable the rest (clearly stating the intention of removing them in > the next release), but still keep if for now. So users get a fair > warning and a timeframe for "fixes", before things are finally > removed. I strongly agree with this. Not every OpenSSL user reads the openssl-dev mailing list (nor -announce). I have been bitten by this in the past in other FOSS projects which only solicited comments from mailing list readers. Disabling (and deprecating) them achieves most of the desired effect anyway as it makes it trivial to identify which bits to remove later on. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine From steve at openssl.org Fri Nov 13 18:15:20 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 13 Nov 2015 18:15:20 +0000 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <56461746.7040808@akamai.com> References: <56460267.1080802@wisemo.com> <56461746.7040808@akamai.com> Message-ID: <20151113181520.GA14277@openssl.org> On Fri, Nov 13, 2015, Benjamin Kaduk wrote: > > As another thread calls to mind, PKCS#12 could potentially just use > triple-DES. (BTW, the CMS tests fail when openssl is configured with > no-rc2, due to this; I have a WIP patch sitting around.) > The issue is that some cuurent software (including major web browsers) still produce PKCS#12 files which include 40 bit RC2 for certificate "encryption" and OpenSSL would fail to decrypt those if it removed RC2. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From noloader at gmail.com Fri Nov 13 18:24:26 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 13 Nov 2015 13:24:26 -0500 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: Message-ID: > ALL BINARY ELLIPTIC CURVES This one may be premature. I understand the TLS WG is moving against it. However, I am aware of implementations of Shoup's ECIES, and they, in turn, depend on OpenSSL. I don't know if the ECIES implementations rely solely on prime fields or not, however. > BLOWFISH - probably still in use though I don't know where exactly? Linux password files and associated tools, like John the Ripper (JtR). OpenSSL is a good toolkit for research purposes. But if research is not a goal, then that's understandable. There are other crypto libraries that include research as a goal. Jeff On Fri, Nov 13, 2015 at 8:40 AM, Emilia K?sper wrote: > Hi all, > > We are considering removing from OpenSSL 1.1 known broken or outdated > cryptographic primitives. As you may know the forks have already done this > but I'd like to seek careful feedback for OpenSSL first to ensure we won't > be breaking any major applications. > > These algorithms are currently candidates for removal: > > CAST > IDEA > MDC2 > MD2 [ already disabled by default ] > RC5 [ already disabled by default ] > RIPEMD > SEED > WHIRLPOOL > ALL BINARY ELLIPTIC CURVES > > My preference would be to remove these algorithms completely (as in, delete > the code). Disabled-by-default code will either be re-enabled by distros (if > there's widespread need for it - in which case we might as well leave it in) > or will be poorly tested and is likely to just silently rot and break. This > code is bloat and maintentance burden for us - my hope is that much of this > code is effectively dead and can be removed. > > Are you aware of any mainstream need to continue supporting these algorithms > in OpenSSL 1.1? Note that an older OpenSSL library or binary, or a > standalone implementation or another crypto toolkit can always be used to > continue supporting a legacy standalone application, or to decrypt > ciphertext from the distant past. I am looking for use cases that could > cause e.g. interop breakage between new and old peers, or major pain to > distro end-users. > > These algorithms are obsolete but removing them doesn't look feasible: > > BLOWFISH - probably still in use though I don't know where exactly? > MD4 - used in NTLM > RC2 - used in PKCS#12 > > Did I miss anything from the list? From pratyush.parimal at gmail.com Fri Nov 13 19:37:46 2015 From: pratyush.parimal at gmail.com (pratyush parimal) Date: Fri, 13 Nov 2015 14:37:46 -0500 Subject: [openssl-dev] Fwd: [openssl-users] How to get list of TLS protocols supported by OpenSSL? In-Reply-To: <5645D9CC.2030608@wisemo.com> References: <5645AEB7.6040608@openssl.org> <5645D9CC.2030608@wisemo.com> Message-ID: Hi guys, I recently confirmed, from the openssl-users mailing list, that there's no suitable API call to determine what TLS versions a given compiled copy of the OpenSSL library is capable of. This would be a functionality that would be useful to a lot of real-world users. I was thinking of implementing this and sending a patch to you guys at rt at openssl.org (or whatever the recommended procedure is), since I think it'll benefit a lot of users. What do you guys think? Moreover, since the list of TLS protocols supported is a property of a particular version of the library, I was thinking of doing it the way SSLeay_version(SSLEAY_VERSION) works. i.e. #define OPENSSL_VERSION_TEXT "OpenSSL 1.0.2a 19 Mar 2015" I'm thinking of adding a #define with a comma-separated list of TLS versions (eg for OpenSSL 1.0.2a): #define OPENSSL_SUPPORTED_TLS_VERSIONS "TLSv1.2,TLSv1.1,TLSv1,SSLv3". This would obvously have to be updated carefully in every release (if needed) just like OPENSSL_VERSION_TEXT must be. I'm interested in contributing code to the openssl project since I use it a lot, and this looks likes a small enough change that'll get me started. Please let me know what you guys think. Thanks, Pratyush Parimal. Software Security Engineer | HPE Vertica ---------- Forwarded message ---------- From: Jakob Bohm Date: Fri, Nov 13, 2015 at 7:38 AM Subject: Re: [openssl-users] How to get list of TLS protocols supported by OpenSSL? To: openssl-users at openssl.org On 13/11/2015 10:34, Matt Caswell wrote: On 13/11/15 02:56, pratyush parimal wrote: Hi, I'm writing a client-server program that uses TLS for communication. I'm wondering if there's any way to programmatically find out which TLS protocol versions are supported by the OpenSSL library installed on my system. I'm currently aware of three ways which "sort of" provide this information: (1) After setting up the TLS communication, call: SSL_get_version(ssl); which returns "TLSV1.2", etc. (2) Try to connect to a server using TLS by specifying all possible TLS versions in the client program, and see which connections pass/fail. (3) Call: SSL_get_ciphers(), print their names, and try to correlate them with the protocol they're associated with. Unfortunately, none of the above answer my question completely. So is it possible to ascertain which TLS protocol versions are actually supported by my server-program, without trying the above methods? My purpose is not to simply make a list for my own reference, but rather finding it out on-the-fly in the server-side program, since I may run it on different versions of OpenSSL. You can use the define TLS_MAX_VERSION to determine the highest protocol version supported by the library. If you also want to know the lowest version then that's a bit more tricky. All current released versions will define OPENSSL_NO_SSL3 if SSLv3 support has been compiled out, and OPENSSL_NO_SSL2 if SSLv2 support has been compiled out (its not currently possible to compile out other protocol versions). In the forthcoming 1.1.0 release SSLv2 support has been completely removed so you don't get OPENSSL_NO_SSL2 even though there is no SSLv2 support available (hmmmm...I wonder if we should add that?). There are other SSLv2 defines in ssl2.h that are removed in 1.1.0 which you could use to detect whether you are on a version with ssl2.h completely removed such as SSL2_MT_ERROR, i.e. something like (completely untested): #ifdef OPENSSL_NO_SSL3 #define TLS_MIN_VERSION TLS1_VERSION #elif defined(OPENSSL_NO_SSL2) || !defined(SSL2_MT_ERROR) #define TLS_MIN_VERSION SSL3_VERSION #else #define TLS_MIN_VERSION SSL2_VERSION #endif How future proof that is if we ever remove SSLv3 support I'm not sure. Matt Unfortunately that presumes that the client is compiled against configure headers from the library build. This is absolutely useless if you try to share an OpenSSL shared library compiled by a 3rd party (such as an OS distribution or an end user). What lots of people need is an ability to interrogate a compiled shared library about what is enabled in that copy, similar to how the SSL_get_ciphers() or similar can be used to determine if the current copy has been compiled without IDEA, ECC or other optional cipher suites. This is what happens in the real world when end users run your compiled program on various Linux distributions, such as Red Hat vs. OpenSUSE vs. Ubuntu... Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Nov 13 19:48:41 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 13 Nov 2015 19:48:41 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <564625F5.1050703@eCosCentric.com> References: <1447434484727.167123.bfa0e6052041fbef094cd397c7d2af1a0f777f4c@spica.telekom.de> <564625F5.1050703@eCosCentric.com> Message-ID: <20151113194841.GP18315@mournblade.imrryr.org> On Fri, Nov 13, 2015 at 06:03:33PM +0000, Jonathan Larmour wrote: > I strongly agree with this. Not every OpenSSL user reads the openssl-dev > mailing list (nor -announce). I have been bitten by this in the past in > other FOSS projects which only solicited comments from mailing list readers. > > Disabling (and deprecating) them achieves most of the desired effect > anyway as it makes it trivial to identify which bits to remove later on. Disabling (from say the DEFAULT cipherlist) works for TLS because users can re-enable by setting a custom cipherlist. Disabling basic cryptographic primitives which are used via EVP by applications for crypto support is much more difficult. The code can be conditionally compiled (with the default to not compile), but users would then have to recompile the library. Distributions would likely delay the visibility of the change by enabling the compilation of the legacy algorithms. There's no easy way to do this. So we need to proceed with care. The simplest approach is to remove ciphersuites from the SSL/TLS code (effectively making them unavailable even via ALL:COMPLEMENTOFALL), but leave the underlying crypto in the library. Similarly, one might remove algorithms from S/MIME, CMS, ... while leaving them in the base crypto library. Only once an algorithm is no longer used by any of the upper layers can we start planning removal from the EVP layer. At this point therefore, I would start by removing SSL/TLS ciphersuite codepoints as suggested (and also 1DES). Whether any of the EVP interfaces are ready for removal, I don't know. -- Viktor. From rsalz at akamai.com Fri Nov 13 20:08:44 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 13 Nov 2015 20:08:44 +0000 Subject: [openssl-dev] OCSP integration into TLS handshake In-Reply-To: <401084E5E73F4241A44F3C9E6FD79428011DFE5B02@exch-01> References: <401084E5E73F4241A44F3C9E6FD79428011DFE5B02@exch-01> Message-ID: <32054ba574d945e497e733abca5d3f5e@usma1ex-dag1mb1.msg.corp.akamai.com> > Has there been/will there be any development towards integrating OCSP checking into the handshake the way CRL checking is, along the lines of Alexander Komyagin's patch from 2012? There are no plans to do so at this time. From dkg at fifthhorseman.net Fri Nov 13 20:20:58 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 13 Nov 2015 15:20:58 -0500 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151113194841.GP18315@mournblade.imrryr.org> References: <1447434484727.167123.bfa0e6052041fbef094cd397c7d2af1a0f777f4c@spica.telekom.de> <564625F5.1050703@eCosCentric.com> <20151113194841.GP18315@mournblade.imrryr.org> Message-ID: <876115lkgl.fsf@alice.fifthhorseman.net> On Fri 2015-11-13 14:48:41 -0500, Viktor Dukhovni wrote: > The simplest approach is to remove ciphersuites from the SSL/TLS > code (effectively making them unavailable even via ALL:COMPLEMENTOFALL), > but leave the underlying crypto in the library. > > Similarly, one might remove algorithms from S/MIME, CMS, ... while > leaving them in the base crypto library. FWIW, this is one of the consequences of OpenSSL providing both libcrypto and libssl. It would be nice from a maintenance perspective to be able to decouple the two more cleanly. I definitely like Viktor's suggestion of removing known-bad mechanisms from libssl. It's harder to know what to do with libcrypto. Perhaps it would be useful to gather data on this by looking at large codebases (e.g. large linux distros like fedora or debian) to see whether these particular functions of libcrypto are being used or linked to. I haven't had the time to do a full review here, but i've found https://codesearch.debian.net/ useful for this kind of API deprecation/removal in the past. e.g.: https://codesearch.debian.net/perpackage-results/MDC2/2/page_0 Unfortunately, OpenSSL has lots of bindings to other languages, so the binding authors themselves might say "we use these functions and offer them to our users", which means there's a chained set of dependencies to consider for proper deprecation. Will removal of these primitives mean that the language bindings won't build against newer versions of OpenSSL? --dkg From rsalz at akamai.com Fri Nov 13 20:34:36 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 13 Nov 2015 20:34:36 +0000 Subject: [openssl-dev] Openssl Memory Leak In-Reply-To: References: Message-ID: ? Can anyone let us know about the leaks and will SSL_FREE() will free the above memory. It should. Try it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.kacvinsky at vectorcast.com Fri Nov 13 20:38:03 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Fri, 13 Nov 2015 15:38:03 -0500 Subject: [openssl-dev] Fwd: Solaris 8, OpenSSL 1.0.1e, not connecting fro our client, but can connect via openssl in client mode In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Tom Kacvinsky Date: Tue, Nov 10, 2015 at 5:51 PM Subject: Solaris 8, OpenSSL 1.0.1e, not connecting fro our client, but can connect via openssl in client mode To: openssl-users at openssl.org I have an interesting case where I am using Solaris 8 (the patchset for which which has /dev/urandom and /dev/random) with OpenSSL 1.0.1e. I can see from my truss logs that we are attempting to connect to a secure web server, but we see nothing in the Apache log files indicating we connect. If I run ./openssl s_client -ssl3 -host XXX.vectorcast.com -port 443 we do indeed connect. So I suspect it is something in the client code we are using. We are using the Qt 4.8.5 SSL client. What should I be on the look out for, so I can file a reasonable support request with Digia? This code works fine on Linux and Windows, so I don't really know at this point if the problem is with Solaris support in Qt, or something lower level in OpenSSL (thought I doubt the latter as openssl in client mode is able to connect). Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Fri Nov 13 20:51:14 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 13 Nov 2015 14:51:14 -0600 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <876115lkgl.fsf@alice.fifthhorseman.net> References: <1447434484727.167123.bfa0e6052041fbef094cd397c7d2af1a0f777f4c@spica.telekom.de> <564625F5.1050703@eCosCentric.com> <20151113194841.GP18315@mournblade.imrryr.org> <876115lkgl.fsf@alice.fifthhorseman.net> Message-ID: <56464D42.9080704@akamai.com> On 11/13/2015 02:20 PM, Daniel Kahn Gillmor wrote: > On Fri 2015-11-13 14:48:41 -0500, Viktor Dukhovni wrote: >> The simplest approach is to remove ciphersuites from the SSL/TLS >> code (effectively making them unavailable even via ALL:COMPLEMENTOFALL), >> but leave the underlying crypto in the library. >> >> Similarly, one might remove algorithms from S/MIME, CMS, ... while >> leaving them in the base crypto library. > FWIW, this is one of the consequences of OpenSSL providing both > libcrypto and libssl. It would be nice from a maintenance perspective > to be able to decouple the two more cleanly. > > I definitely like Viktor's suggestion of removing known-bad mechanisms > from libssl. It's harder to know what to do with libcrypto. I am hopeful that some things can still be done with libcrypto, but recognize that that may be overly optimistic. > Unfortunately, OpenSSL has lots of bindings to other languages, so the > binding authors themselves might say "we use these functions and offer > them to our users", which means there's a chained set of dependencies > to consider for proper deprecation. Will removal of these primitives > mean that the language bindings won't build against newer versions of > OpenSSL? > Yes. https://rt.cpan.org/Public/Bug/Display.html?id=106180 is just one case of many, I fear... -Ben From valerie.fenwick at oracle.com Fri Nov 13 21:06:38 2015 From: valerie.fenwick at oracle.com (Valerie Fenwick) Date: Fri, 13 Nov 2015 13:06:38 -0800 Subject: [openssl-dev] Fwd: Solaris 8, OpenSSL 1.0.1e, not connecting fro our client, but can connect via openssl in client mode In-Reply-To: References: Message-ID: <564650DE.3060307@oracle.com> Why are you running on such an old OS? How old are your Windows and Linux systems? Certainly not of the same generation. Solaris 8 & 9 are no longer supported, so you can't get security patches or anything. I highly recommend you try at least S10, or better, yet - S11. the /dev/[u]random on S8 is a far cry from what is in our modern OSes. Valerie On 11/13/2015 12:38 PM, Tom Kacvinsky wrote: > > ---------- Forwarded message ---------- > From: *Tom Kacvinsky* > > Date: Tue, Nov 10, 2015 at 5:51 PM > Subject: Solaris 8, OpenSSL 1.0.1e, not connecting fro our client, but can > connect via openssl in client mode > To: openssl-users at openssl.org > > > I have an interesting case where I am using Solaris 8 (the patchset for which > which has /dev/urandom and /dev/random) with OpenSSL 1.0.1e. I can see from my > truss logs that we are attempting to connect to a secure web server, but we see > nothing in the Apache log files indicating we connect. > > If I run > > ./openssl s_client -ssl3 -host XXX.vectorcast.com -port 443 > > we do indeed connect. So I suspect it is something in the client code we are > using. We are using the Qt 4.8.5 SSL client. What should I be on the look out > for, so I can file a reasonable support request with Digia? This code works > fine on Linux and Windows, so I don't really know at this point if the problem > is with Solaris support in Qt, or something lower level in OpenSSL (thought I > doubt the latter as openssl in client mode is able to connect). > > Thanks, > > Tom > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva Solaris Cryptographic & Key Management Technologies, Manager Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054. From tom.kacvinsky at vectorcast.com Fri Nov 13 21:12:08 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Fri, 13 Nov 2015 16:12:08 -0500 Subject: [openssl-dev] Fwd: Solaris 8, OpenSSL 1.0.1e, not connecting fro our client, but can connect via openssl in client mode In-Reply-To: <564650DE.3060307@oracle.com> References: <564650DE.3060307@oracle.com> Message-ID: Hi Valerie, On Fri, Nov 13, 2015 at 4:06 PM, Valerie Fenwick wrote: > Why are you running on such an old OS? How old are your Windows and Linux > systems? Certainly not of the same generation. > > We still support S8 because some of our very important customers are still using it. Linux is faisly new Ubuntu 12.04, Windows is at 7. Solaris 8 & 9 are no longer supported, so you can't get security patches > or anything. > > Yeah, I know. Could use some patches related to the linker being slow, but that is beyond the scope of this email. > I highly recommend you try at least S10, or better, yet - S11. > > I built on S8 (we might use S10 in the future). But I also ran on S10 and had the same issue. I really think the problem is in the Qt code, as that really is the OpenSSL client code (we just call their API). What I am after is what in their code would cause a problem that the openssl executable does not have. Once I have that information, I can contact the Qt maintainers with a bug report. the /dev/[u]random on S8 is a far cry from what is in our modern OSes. > > Valerie > > On 11/13/2015 12:38 PM, Tom Kacvinsky wrote: > >> >> ---------- Forwarded message ---------- >> From: *Tom Kacvinsky* > > >> Date: Tue, Nov 10, 2015 at 5:51 PM >> Subject: Solaris 8, OpenSSL 1.0.1e, not connecting fro our client, but can >> connect via openssl in client mode >> To: openssl-users at openssl.org >> >> >> I have an interesting case where I am using Solaris 8 (the patchset for >> which >> which has /dev/urandom and /dev/random) with OpenSSL 1.0.1e. I can see >> from my >> truss logs that we are attempting to connect to a secure web server, but >> we see >> nothing in the Apache log files indicating we connect. >> >> If I run >> >> ./openssl s_client -ssl3 -host XXX.vectorcast.com >> -port 443 >> >> we do indeed connect. So I suspect it is something in the client code we >> are >> using. We are using the Qt 4.8.5 SSL client. What should I be on the >> look out >> for, so I can file a reasonable support request with Digia? This code >> works >> fine on Linux and Windows, so I don't really know at this point if the >> problem >> is with Solaris support in Qt, or something lower level in OpenSSL >> (thought I >> doubt the latter as openssl in client mode is able to connect). >> >> Thanks, >> >> Tom >> >> >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >> >> > -- > Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva > Solaris Cryptographic & Key Management Technologies, Manager > Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054. > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Nov 13 21:16:56 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 13 Nov 2015 21:16:56 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <876115lkgl.fsf@alice.fifthhorseman.net> References: <1447434484727.167123.bfa0e6052041fbef094cd397c7d2af1a0f777f4c@spica.telekom.de> <564625F5.1050703@eCosCentric.com> <20151113194841.GP18315@mournblade.imrryr.org> <876115lkgl.fsf@alice.fifthhorseman.net> Message-ID: <20151113211656.GQ18315@mournblade.imrryr.org> On Fri, Nov 13, 2015 at 03:20:58PM -0500, Daniel Kahn Gillmor wrote: > Perhaps it would be useful to gather data on this by looking at large > codebases (e.g. large linux distros like fedora or debian) to see > whether these particular functions of libcrypto are being used or linked > to. > > I haven't had the time to do a full review here, but i've found > https://codesearch.debian.net/ useful for this kind of API > deprecation/removal in the past. This is very difficult, because most applications use libcrypto algorithms indirectly, via EVP_get_cipherbyname(), EVP_get_digestbyname() and so on. So the code will link, but there'll be runtime errors due to missing ciphers or digests. Even worse, we will find that things like Python, Perl, ... provide EVP wrappers, and then it is a mystery which scripts depend on obsolete ciphers. At some point people will just need to port their scripts. This does present rather a quandry for distributions shipping Perl, Python, ... as to which OpenSSL to link to, if newer versions omit base algorithms. Actually deleting algorithms is *very* difficult. Fixing the SSL layer is much more simple, because algorithm negotiation (i.e. algorithm agility, which many folks like to knock) means that TLS can move on much more easily that some random application that needs to read 20-year-old backups. -- Viktor. From rsalz at akamai.com Fri Nov 13 21:20:47 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 13 Nov 2015 21:20:47 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151113211656.GQ18315@mournblade.imrryr.org> References: <1447434484727.167123.bfa0e6052041fbef094cd397c7d2af1a0f777f4c@spica.telekom.de> <564625F5.1050703@eCosCentric.com> <20151113194841.GP18315@mournblade.imrryr.org> <876115lkgl.fsf@alice.fifthhorseman.net> <20151113211656.GQ18315@mournblade.imrryr.org> Message-ID: <140967ab0756449ab177bcf74684a97d@usma1ex-dag1mb1.msg.corp.akamai.com> > Actually deleting algorithms is *very* difficult. Yes. And we're doing the best we can by asking reasonably. Some people may get burnt. Oh well. It's open source, fork if you have to. From valerie.fenwick at oracle.com Fri Nov 13 21:26:34 2015 From: valerie.fenwick at oracle.com (Valerie Fenwick) Date: Fri, 13 Nov 2015 13:26:34 -0800 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <140967ab0756449ab177bcf74684a97d@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1447434484727.167123.bfa0e6052041fbef094cd397c7d2af1a0f777f4c@spica.telekom.de> <564625F5.1050703@eCosCentric.com> <20151113194841.GP18315@mournblade.imrryr.org> <876115lkgl.fsf@alice.fifthhorseman.net> <20151113211656.GQ18315@mournblade.imrryr.org> <140967ab0756449ab177bcf74684a97d@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <5646558A.7060406@oracle.com> On 11/13/2015 1:20 PM, Salz, Rich wrote: >> Actually deleting algorithms is *very* difficult. > > Yes. > > And we're doing the best we can by asking reasonably. > > Some people may get burnt. Oh well. It's open source, fork if you have to. With all of the "unacceptable" rules coming down from Gov'ts and corp CSOs, you'll soon find more people want them out than left in. They become dangerous, as the code rots and nobody looks at it. And, worse, people could use it and think it's okay because it's there. Disabled by default is good, gone (for some of these) is better. People will have to modernize - things will break, and we will have to tell them: "wow, what you're doing is horribly insecure, thank goodness your application stopped running so you could know to go fix this". yes, there will be applications that haven't been updated in years that "depend" on these algorithms. But, what other security bugs lurk in there? Those applications likely should not be used, should be modernized or replaced. Given how big the changes are for 1.1.0, it seems like a generally reasonable time to do this. Valerie -- Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva Solaris Cryptographic & Key Management Technologies, Manager Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054. From openssl-users at dukhovni.org Fri Nov 13 21:56:25 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 13 Nov 2015 21:56:25 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <140967ab0756449ab177bcf74684a97d@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1447434484727.167123.bfa0e6052041fbef094cd397c7d2af1a0f777f4c@spica.telekom.de> <564625F5.1050703@eCosCentric.com> <20151113194841.GP18315@mournblade.imrryr.org> <876115lkgl.fsf@alice.fifthhorseman.net> <20151113211656.GQ18315@mournblade.imrryr.org> <140967ab0756449ab177bcf74684a97d@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20151113215624.GR18315@mournblade.imrryr.org> On Fri, Nov 13, 2015 at 09:20:47PM +0000, Salz, Rich wrote: > > Actually deleting algorithms is *very* difficult. > > Yes. > > And we're doing the best we can by asking reasonably. > > Some people may get burnt. Oh well. It's open source, fork if you have to. What we primarily don't want to happen is to delay the use of OpenSSL 1.1.0 because it breaks too much. If we ensure that TLS is free of weak crypto, but (for now) leave some weaker crypto in the library, so that platforms can deliver the new libcrypto in /usr/lib and not break existing applications, I think that's more useful that immediately breaking builds of all applications that happen to touch legacy crypto. So I'm trying to help move forward, without creating artificial barriers. Let's fix TLS (libssl) first, and we can tackle libcrypto in a later release. -- Viktor. From rsalz at akamai.com Fri Nov 13 22:02:02 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 13 Nov 2015 22:02:02 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151113215624.GR18315@mournblade.imrryr.org> References: <1447434484727.167123.bfa0e6052041fbef094cd397c7d2af1a0f777f4c@spica.telekom.de> <564625F5.1050703@eCosCentric.com> <20151113194841.GP18315@mournblade.imrryr.org> <876115lkgl.fsf@alice.fifthhorseman.net> <20151113211656.GQ18315@mournblade.imrryr.org> <140967ab0756449ab177bcf74684a97d@usma1ex-dag1mb1.msg.corp.akamai.com> <20151113215624.GR18315@mournblade.imrryr.org> Message-ID: <7e49287e4f6b4406a2f8d93fd38fe914@usma1ex-dag1mb1.msg.corp.akamai.com> > So I'm trying to help move forward, without creating artificial barriers. Let's fix TLS (libssl) first, and we can tackle libcrypto in a later release. I disagree. I think the main driver will be OpenSSL 1.1-next, which will have TLS 1.3 support. So the purpose of this realease will be to flush out bad code and bad crypto, completely refresh and overhaul many things. And if some folks wait because they need to still use old, bad or unsupported, crypto algorithms, so be it. Can't please everyone. And they've got time to fix it before they decide they really really want TLS 1.3 :) So I don't view this as an artificial barrier. I view it as a preview for the real thing people will want, which is the *next* release. /r$ From rt at openssl.org Fri Nov 13 22:20:56 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 13 Nov 2015 22:20:56 +0000 Subject: [openssl-dev] [openssl.org #2667] Add -starttls irc support to s_client In-Reply-To: <20111220202926.GM10880@ohnopublishing.net> References: <20111220202926.GM10880@ohnopublishing.net> Message-ID: Done in master. Thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From dkg at fifthhorseman.net Fri Nov 13 22:24:01 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 13 Nov 2015 17:24:01 -0500 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151113211656.GQ18315@mournblade.imrryr.org> References: <1447434484727.167123.bfa0e6052041fbef094cd397c7d2af1a0f777f4c@spica.telekom.de> <564625F5.1050703@eCosCentric.com> <20151113194841.GP18315@mournblade.imrryr.org> <876115lkgl.fsf@alice.fifthhorseman.net> <20151113211656.GQ18315@mournblade.imrryr.org> Message-ID: <87twopk072.fsf@alice.fifthhorseman.net> On Fri 2015-11-13 16:16:56 -0500, Viktor Dukhovni wrote: > This is very difficult, because most applications use libcrypto > algorithms indirectly, via EVP_get_cipherbyname(), EVP_get_digestbyname() > and so on. So the code will link, but there'll be runtime errors > due to missing ciphers or digests. I'm less sympathetic in this case, since these functions have well-defined semantics when a cipher has been removed (or simply isn't present in the first place): they return NULL on error, and if code X doesn't handle errors properly, it's up to code X to fix that problem. Of course, no one will catch this at compile time, or even at dynamic link time -- it'll get "caught" at runtime, which probably means codepaths that haven't been tickled maybe ever. At any rate, it's not hard to search for uses of EVP_get_*byname [0] -- places where those are used with hard-coded strings without error checking can be ferreted out and fixed, and places where they're invoked indirectly should probably just pass the error message upward in the stack, no? --dkg [0] https://codesearch.debian.net/perpackage-results/EVP_get_%5Ba-z%5D*byname/2/page_0 From openssl-users at dukhovni.org Fri Nov 13 22:55:41 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 13 Nov 2015 22:55:41 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <87twopk072.fsf@alice.fifthhorseman.net> References: <1447434484727.167123.bfa0e6052041fbef094cd397c7d2af1a0f777f4c@spica.telekom.de> <564625F5.1050703@eCosCentric.com> <20151113194841.GP18315@mournblade.imrryr.org> <876115lkgl.fsf@alice.fifthhorseman.net> <20151113211656.GQ18315@mournblade.imrryr.org> <87twopk072.fsf@alice.fifthhorseman.net> Message-ID: <20151113225540.GS18315@mournblade.imrryr.org> On Fri, Nov 13, 2015 at 05:24:01PM -0500, Daniel Kahn Gillmor wrote: > I'm less sympathetic in this case, since these functions have > well-defined semantics when a cipher has been removed (or simply isn't > present in the first place): they return NULL on error, and if code X > doesn't handle errors properly, it's up to code X to fix that problem. I think we can agree that link-time errors are preferrable to run-time errors. The latter are far less obvious to distribution maintainers who build lots of software, but don't necessarily have code-coverage tests for it, and don't even know what user-developed scripts do. > Of course, no one will catch this at compile time, or even at dynamic > link time -- it'll get "caught" at runtime, which probably means > codepaths that haven't been tickled maybe ever. Yes, some code will break. It may no longer be able to decrypt old files, or read archived S/MIME messages. > At any rate, it's not hard to search for uses of EVP_get_*byname [0] -- > places where those are used with hard-coded strings without error > checking can be ferreted out and fixed, and places where they're invoked > indirectly should probably just pass the error message upward in the > stack, no? Often the strings are not hard-coded, they are chosen by all kinds of code that uses the library that wraps the EVP interface. -- Viktor. From uri at ll.mit.edu Fri Nov 13 22:14:31 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 13 Nov 2015 22:14:31 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback Message-ID: <20151113221440.17788994.14884.34705@ll.mit.edu> FWIW, I agree with Viktor. ? ? Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Salz, Rich? Sent: Friday, November 13, 2015 17:02 To: openssl-dev at openssl.org Reply To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback ? ? > So I'm trying to help move forward, without creating artificial barriers. Let's fix TLS (libssl) first, and we can tackle libcrypto in a later release. I disagree. I think the main driver will be OpenSSL 1.1-next, which will have TLS 1.3 support. So the purpose of this realease will be to flush out bad code and bad crypto, completely refresh and overhaul many things. And if some folks wait because they need to still use old, bad or unsupported, crypto algorithms, so be it. Can't please everyone. And they've got time to fix it before they decide they really really want TLS 1.3 :) So I don't view this as an artificial barrier. I view it as a preview for the real thing people will want, which is the *next* release. ? /r$ _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From openssl-users at dukhovni.org Sat Nov 14 01:53:54 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 14 Nov 2015 01:53:54 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <7e49287e4f6b4406a2f8d93fd38fe914@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1447434484727.167123.bfa0e6052041fbef094cd397c7d2af1a0f777f4c@spica.telekom.de> <564625F5.1050703@eCosCentric.com> <20151113194841.GP18315@mournblade.imrryr.org> <876115lkgl.fsf@alice.fifthhorseman.net> <20151113211656.GQ18315@mournblade.imrryr.org> <140967ab0756449ab177bcf74684a97d@usma1ex-dag1mb1.msg.corp.akamai.com> <20151113215624.GR18315@mournblade.imrryr.org> <7e49287e4f6b4406a2f8d93fd38fe914@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20151114015354.GT18315@mournblade.imrryr.org> On Fri, Nov 13, 2015 at 10:02:02PM +0000, Salz, Rich wrote: > > So I'm trying to help move forward, without creating artificial barriers. > > Let's fix TLS (libssl) first, and we can tackle libcrypto in a later > > release. > > I disagree. > > I think the main driver will be OpenSSL 1.1-next, which will have TLS 1.3 > support. For me, the main driver will be all the internal code quality improvements in OpenSSL 1.1.0, that I hope will make the code substantially more resilient, and subject to a lower CVE rate than its predecessors. Hardening of the existing TLS 1.2 implementation will also be a win. Sexy new features like TLS 1.3 will not be compelling for quite some time. I do not want to dissuade downstream distributions from adopting OpenSSL 1.1.0 because porting is difficult to impossible. > So the purpose of this realease will be to flush out bad code > and bad crypto, completely refresh and overhaul many things. And if some > folks wait because they need to still use old, bad or unsupported, crypto > algorithms, so be it. Can't please everyone. And they've got time to > fix it before they decide they really really want TLS 1.3 :) This may not take into account the compexity of the ecosystem, the folks with "bad code and bad crypto" are not necessarily the distribution maintainers who ship prebuilt packages, libraries, and scripting languages. Which OpenSSL should Perl's Net::SSLeay link against? Or some CPAN module that provides libcrypto algorithms? The distribution maintainers face immense backwards compatibility challenges, especially with late binding software. We cannot be cavalier about their problems. > So I don't view this as an artificial barrier. I view it as a preview > for the real thing people will want, which is the *next* release. I expect on the contrary, that a more solid 1.1.0 is more compelling than a shiny 1.2.0. Just adjusting to the API changes will be enough work, and we want that work to start. At least those show up at link time. Delaying the API adjustment by removing functionality is likely too radical. Yes we'd prefer to not maintain the old ciphers and digests forever, but as soon as we're doing something other than TLS, we're supporting data at rest not just data in motion, and data at rest has a rather long shelf-life. Sadly, we have to tread very carefully with algorithm removal from libcrypto, but we have a lot more flexibility in libssl. -- Viktor. From pwalten at au1.ibm.com Sat Nov 14 07:32:33 2015 From: pwalten at au1.ibm.com (Peter Waltenberg) Date: Sat, 14 Nov 2015 07:32:33 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151114015354.GT18315@mournblade.imrryr.org> References: <20151114015354.GT18315@mournblade.imrryr.org>, <1447434484727.167123.bfa0e6052041fbef094cd397c7d2af1a0f777f4c@spica.telekom.de> <564625F5.1050703@eCosCentric.com> <20151113194841.GP18315@mournblade.imrryr.org> <876115lkgl.fsf@alice.fifthhorseman.net> <20151113211656.GQ18315@mournblade.imrryr.org> <140967ab0756449ab177bcf74684a97d@usma1ex-dag1mb1.msg.corp.akamai.com> <20151113215624.GR18315@mournblade.imrryr.org> <7e49287e4f6b4406a2f8d93fd38fe914@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <201511140733.tAE7XdL3004819@d23av05.au.ibm.com> An HTML attachment was scrubbed... URL: From jyothi.v at freescale.com Sat Nov 14 10:37:59 2015 From: jyothi.v at freescale.com (Vemulapalli Jyothi) Date: Sat, 14 Nov 2015 10:37:59 +0000 Subject: [openssl-dev] procedure for adding new engine registration In-Reply-To: <5645CCED.2000804@openssl.org> References: <5645B361.7040908@openssl.org> <5645CCED.2000804@openssl.org> Message-ID: Thanks Matt. We will try. Best regards Jyothi -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Friday, November 13, 2015 5:14 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] procedure for adding new engine registration On 13/11/15 11:16, Vemulapalli Jyothi wrote: > Hi Matt, > > Very useful information. > > I too agree with you that we need not have a new engine distribution. > > I see some options like dynamic engines and static engine support. > > If we have built a library with dynamic engine interface, how can we do speed test using openssl speed command. As follows (on Linux): OPENSSL_ENGINES=/path/to/my/engine/dir openssl speed -engine myengine Matt _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Sat Nov 14 11:29:36 2015 From: rt at openssl.org (Marcus Meissner via RT) Date: Sat, 14 Nov 2015 11:29:36 +0000 Subject: [openssl-dev] [openssl.org #4140] GITHUB PULL REQUEST: do not load engines twice In-Reply-To: <20151114112920.GB29696@suse.de> References: <20151114112920.GB29696@suse.de> Message-ID: Hi, https://github.com/openssl/openssl/pull/466 If you try to run OPENSSL_config twice, it will fail on loading engines. (We encountered this case with ruby and libzypp both running OPENSSL_config in the same process.) Ciao, Marcus -- Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From openssl-users at dukhovni.org Sat Nov 14 17:32:16 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 14 Nov 2015 17:32:16 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <201511140733.tAE7XdL3004819@d23av05.au.ibm.com> References: <1447434484727.167123.bfa0e6052041fbef094cd397c7d2af1a0f777f4c@spica.telekom.de> <564625F5.1050703@eCosCentric.com> <20151113194841.GP18315@mournblade.imrryr.org> <876115lkgl.fsf@alice.fifthhorseman.net> <20151113211656.GQ18315@mournblade.imrryr.org> <140967ab0756449ab177bcf74684a97d@usma1ex-dag1mb1.msg.corp.akamai.com> <20151113215624.GR18315@mournblade.imrryr.org> <7e49287e4f6b4406a2f8d93fd38fe914@usma1ex-dag1mb1.msg.corp.akamai.com> <201511140733.tAE7XdL3004819@d23av05.au.ibm.com> Message-ID: <20151114173215.GX18315@mournblade.imrryr.org> On Sat, Nov 14, 2015 at 07:32:33AM +0000, Peter Waltenberg wrote: > I also can't see any point expunging old algorithms from the sources, > making them not build by default should be enough. It is difficult enough to maintain code that is typically built, dead code is even harder to keep correct. And what are distributions of the library to do? Break a lot of customer code by shipping with the algorithms disabled? Or re-enable compilation? > The only thing I would suggest is dropping assembler support for > anything that's been retired, just to cut the maintenance effort / risk > of breakage. If it's legacy only, performance shouldn't be an issue. That probably makes more sense. Drop associated SSL/TLS ciphersuite codepoints and drop assembly support (if any). Leave the C implementation in libcrypto to support legacy "data at rest" applications. The proposed list was: CAST IDEA MDC2 MD2 [ already disabled by default ] RC5 [ already disabled by default ] RIPEMD SEED WHIRLPOOL ALL BINARY ELLIPTIC CURVES If I were to guess, it would be that the base crypto implementations of IDEA, SEED and binary elliptic curves need to stay. We could perhaps get away with removing CAST and RIPEMD. No idea about the rest. -- Viktor. From pl at artisanlogiciel.net Sun Nov 15 08:48:36 2015 From: pl at artisanlogiciel.net (pl) Date: Sun, 15 Nov 2015 09:48:36 +0100 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151114173215.GX18315@mournblade.imrryr.org> References: <1447434484727.167123.bfa0e6052041fbef094cd397c7d2af1a0f777f4c@spica.telekom.de> <564625F5.1050703@eCosCentric.com> <20151113194841.GP18315@mournblade.imrryr.org> <876115lkgl.fsf@alice.fifthhorseman.net> <20151113211656.GQ18315@mournblade.imrryr.org> <140967ab0756449ab177bcf74684a97d@usma1ex-dag1mb1.msg.corp.akamai.com> <20151113215624.GR18315@mournblade.imrryr.org> <7e49287e4f6b4406a2f8d93fd38fe914@usma1ex-dag1mb1.msg.corp.akamai.com> <201511140733.tAE7XdL3004819@d23av05.au.ibm.com> <20151114173215.GX18315@mournblade.imrryr.org> Message-ID: <564846E4.4060403@artisanlogiciel.net> On 14/11/2015 18:32, Viktor Dukhovni wrote: > On Sat, Nov 14, 2015 at 07:32:33AM +0000, Peter Waltenberg wrote: > >> I also can't see any point expunging old algorithms from the sources, >> making them not build by default should be enough. > It is difficult enough to maintain code that is typically built, > dead code is even harder to keep correct. And what are distributions > of the library to do? Break a lot of customer code by shipping > with the algorithms disabled? Or re-enable compilation? > >> The only thing I would suggest is dropping assembler support for >> anything that's been retired, just to cut the maintenance effort / risk >> of breakage. If it's legacy only, performance shouldn't be an issue. > That probably makes more sense. Drop associated SSL/TLS ciphersuite > codepoints and drop assembly support (if any). Leave the C > implementation in libcrypto to support legacy "data at rest" > applications. > > The proposed list was: > > CAST > IDEA > MDC2 > MD2 [ already disabled by default ] > RC5 [ already disabled by default ] > RIPEMD > SEED > WHIRLPOOL > ALL BINARY ELLIPTIC CURVES > > If I were to guess, it would be that the base crypto implementations > of IDEA, SEED and binary elliptic curves need to stay. We could > perhaps get away with removing CAST and RIPEMD. No idea about the > rest. > It is perhaps time to split crypto library in two libraries libcryptolegacy and libcryptostrong... My two cents. Philippe L. From rt at openssl.org Sun Nov 15 10:04:28 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Sun, 15 Nov 2015 10:04:28 +0000 Subject: [openssl-dev] [openssl.org #4141] GOST ciphersuites In-Reply-To: References: Message-ID: Hello! In the commit 5e3d21fef150f020e2d33439401da8f7e311aa24 you set the SSL_SSLV3 for the GOST ciphersuites. But the GOST ciphersuites are not usable with SSLv3, they require TLSv1. Could you turn the flag back for the GOST ciphersuites? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From loganaden at gmail.com Sun Nov 15 10:24:02 2015 From: loganaden at gmail.com (Loganaden Velvindron) Date: Sun, 15 Nov 2015 10:24:02 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <564846E4.4060403@artisanlogiciel.net> References: <1447434484727.167123.bfa0e6052041fbef094cd397c7d2af1a0f777f4c@spica.telekom.de> <564625F5.1050703@eCosCentric.com> <20151113194841.GP18315@mournblade.imrryr.org> <876115lkgl.fsf@alice.fifthhorseman.net> <20151113211656.GQ18315@mournblade.imrryr.org> <140967ab0756449ab177bcf74684a97d@usma1ex-dag1mb1.msg.corp.akamai.com> <20151113215624.GR18315@mournblade.imrryr.org> <7e49287e4f6b4406a2f8d93fd38fe914@usma1ex-dag1mb1.msg.corp.akamai.com> <201511140733.tAE7XdL3004819@d23av05.au.ibm.com> <20151114173215.GX18315@mournblade.imrryr.org> <564846E4.4060403@artisanlogiciel.net> Message-ID: On Sun, Nov 15, 2015 at 8:48 AM, pl wrote: > On 14/11/2015 18:32, Viktor Dukhovni wrote: >> On Sat, Nov 14, 2015 at 07:32:33AM +0000, Peter Waltenberg wrote: >> >>> I also can't see any point expunging old algorithms from the sources, >>> making them not build by default should be enough. >> It is difficult enough to maintain code that is typically built, >> dead code is even harder to keep correct. And what are distributions >> of the library to do? Break a lot of customer code by shipping >> with the algorithms disabled? Or re-enable compilation? >> >>> The only thing I would suggest is dropping assembler support for >>> anything that's been retired, just to cut the maintenance effort / risk >>> of breakage. If it's legacy only, performance shouldn't be an issue. >> That probably makes more sense. Drop associated SSL/TLS ciphersuite >> codepoints and drop assembly support (if any). Leave the C >> implementation in libcrypto to support legacy "data at rest" >> applications. >> >> The proposed list was: >> >> CAST >> IDEA >> MDC2 >> MD2 [ already disabled by default ] >> RC5 [ already disabled by default ] >> RIPEMD >> SEED >> WHIRLPOOL >> ALL BINARY ELLIPTIC CURVES >> Perhaps, it might be worth looking at what LibreSSL has already removed without affecting their 3rd party packages ? From levitte at openssl.org Sun Nov 15 12:11:37 2015 From: levitte at openssl.org (Richard Levitte) Date: Sun, 15 Nov 2015 13:11:37 +0100 (CET) Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <564846E4.4060403@artisanlogiciel.net> References: <201511140733.tAE7XdL3004819@d23av05.au.ibm.com> <20151114173215.GX18315@mournblade.imrryr.org> <564846E4.4060403@artisanlogiciel.net> Message-ID: <20151115.131137.112755789873515120.levitte@openssl.org> In message <564846E4.4060403 at artisanlogiciel.net> on Sun, 15 Nov 2015 09:48:36 +0100, pl said: pl> On 14/11/2015 18:32, Viktor Dukhovni wrote: pl> > The proposed list was: pl> > pl> > CAST pl> > IDEA pl> > MDC2 pl> > MD2 [ already disabled by default ] pl> > RC5 [ already disabled by default ] pl> > RIPEMD pl> > SEED pl> > WHIRLPOOL pl> > ALL BINARY ELLIPTIC CURVES pl> > pl> > If I were to guess, it would be that the base crypto implementations pl> > of IDEA, SEED and binary elliptic curves need to stay. We could pl> > perhaps get away with removing CAST and RIPEMD. No idea about the pl> > rest. pl> > pl> pl> It is perhaps time to split crypto library in two libraries pl> libcryptolegacy and libcryptostrong... pl> pl> My two cents. I though could be to make a "legacy" engine that holds the removed crypto algos. It could be maintained outside of mainstream OpenSSL, really by anyone... Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl-users at dukhovni.org Sun Nov 15 17:00:27 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 15 Nov 2015 17:00:27 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <20151113194841.GP18315@mournblade.imrryr.org> <876115lkgl.fsf@alice.fifthhorseman.net> <20151113211656.GQ18315@mournblade.imrryr.org> <140967ab0756449ab177bcf74684a97d@usma1ex-dag1mb1.msg.corp.akamai.com> <20151113215624.GR18315@mournblade.imrryr.org> <7e49287e4f6b4406a2f8d93fd38fe914@usma1ex-dag1mb1.msg.corp.akamai.com> <201511140733.tAE7XdL3004819@d23av05.au.ibm.com> <20151114173215.GX18315@mournblade.imrryr.org> <564846E4.4060403@artisanlogiciel.net> Message-ID: <20151115170026.GZ18315@mournblade.imrryr.org> On Sun, Nov 15, 2015 at 10:24:02AM +0000, Loganaden Velvindron wrote: > Perhaps, it might be worth looking at what LibreSSL has already > removed without affecting their 3rd party packages ? There are not many arms-length packages for OpenBSD, the ports are maintained by the same crowd as the OS. Nor very many users of all the BSD'd combined (I'm editing this email on a BSD server). This would not be a very meaningful datapoint. -- Viktor. From openssl-users at dukhovni.org Sun Nov 15 17:09:48 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 15 Nov 2015 17:09:48 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151115.131137.112755789873515120.levitte@openssl.org> References: <201511140733.tAE7XdL3004819@d23av05.au.ibm.com> <20151114173215.GX18315@mournblade.imrryr.org> <564846E4.4060403@artisanlogiciel.net> <20151115.131137.112755789873515120.levitte@openssl.org> Message-ID: <20151115170948.GA18315@mournblade.imrryr.org> On Sun, Nov 15, 2015 at 01:11:37PM +0100, Richard Levitte wrote: > pl> It is perhaps time to split crypto library in two libraries > pl> libcryptolegacy and libcryptostrong... > pl> > pl> My two cents. > > I though could be to make a "legacy" engine that holds the removed > crypto algos. It could be maintained outside of mainstream OpenSSL, > really by anyone... If the engine is not automatically loaded, then scripting languages that provide wrappers around the various algorithms, as does other software that needs the legacy algoriths, but has never needed any engines and makes no provisions for loading any. With a separate library one might imagine its "init" method calling some function in libcrypto that makes the legacy algorithms available via EVP, and then Python, Perl, ... could be linked with: -lweakcrypto -lssl -lcrypto That's something distribution maintainers could do, but is this really a productive step to take at this time? That library will take more effort to produce than leaving things as they are. -- Viktor. From levitte at openssl.org Sun Nov 15 20:14:43 2015 From: levitte at openssl.org (Richard Levitte) Date: Sun, 15 Nov 2015 21:14:43 +0100 (CET) Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151115170948.GA18315@mournblade.imrryr.org> References: <564846E4.4060403@artisanlogiciel.net> <20151115.131137.112755789873515120.levitte@openssl.org> <20151115170948.GA18315@mournblade.imrryr.org> Message-ID: <20151115.211443.707757402410466628.levitte@openssl.org> In message <20151115170948.GA18315 at mournblade.imrryr.org> on Sun, 15 Nov 2015 17:09:48 +0000, Viktor Dukhovni said: openssl-users> On Sun, Nov 15, 2015 at 01:11:37PM +0100, Richard Levitte wrote: openssl-users> openssl-users> > pl> It is perhaps time to split crypto library in two libraries openssl-users> > pl> libcryptolegacy and libcryptostrong... openssl-users> > pl> openssl-users> > pl> My two cents. openssl-users> > openssl-users> > I though could be to make a "legacy" engine that holds the removed openssl-users> > crypto algos. It could be maintained outside of mainstream OpenSSL, openssl-users> > really by anyone... openssl-users> openssl-users> If the engine is not automatically loaded, then scripting languages openssl-users> that provide wrappers around the various algorithms, as does other openssl-users> software that needs the legacy algoriths, but has never needed any openssl-users> engines and makes no provisions for loading any. /PATH/TO/openssl.cnf: openssl_conf = openssl_init [openssl_init] engines = default_engines [default_engines] legacy = legacy [legacy] engine_id = legacy init = 1 default_algorithms = cast, idea, mdc2, md2, rc5, ripemd, seed, whirlpool, ... -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl-users at dukhovni.org Sun Nov 15 21:16:23 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 15 Nov 2015 21:16:23 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151115.211443.707757402410466628.levitte@openssl.org> References: <564846E4.4060403@artisanlogiciel.net> <20151115.131137.112755789873515120.levitte@openssl.org> <20151115170948.GA18315@mournblade.imrryr.org> <20151115.211443.707757402410466628.levitte@openssl.org> Message-ID: <20151115211623.GD18315@mournblade.imrryr.org> On Sun, Nov 15, 2015 at 09:14:43PM +0100, Richard Levitte wrote: > openssl-users> If the engine is not automatically loaded, then scripting languages > openssl-users> that provide wrappers around the various algorithms [break], as does other > openssl-users> software that needs the legacy algoriths, but has never needed any > openssl-users> engines and makes no provisions for loading any. > > /PATH/TO/openssl.cnf: > > openssl_conf = openssl_init > > [openssl_init] > engines = default_engines > > [default_engines] > legacy = legacy > > [legacy] > engine_id = legacy > init = 1 > default_algorithms = cast, idea, mdc2, md2, rc5, ripemd, seed, whirlpool, ... There's lots of code that does not read any ".cnf" files. The CONF interface has not historically been terribly well documented. What happens if the engine fails to load? Are any environment variables that determine CONF file locations honoured in setuid/setgid programs (do we use secure_getenv(3) where available?). We'd need to provide a migration document and code samples, that show how to do "CONF" initialization, and of course create the legacy engine. All this may delay adoption, as distributions will need patch upstream code to perform such initialization. Is the pain worth the gain? I'm inclined to think that dropping TLS ciphersuite code points, and assembly support, is a rather sensible first step. -- Viktor. From matt at openssl.org Sun Nov 15 23:34:38 2015 From: matt at openssl.org (Matt Caswell) Date: Sun, 15 Nov 2015 23:34:38 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151115211623.GD18315@mournblade.imrryr.org> References: <564846E4.4060403@artisanlogiciel.net> <20151115.131137.112755789873515120.levitte@openssl.org> <20151115170948.GA18315@mournblade.imrryr.org> <20151115.211443.707757402410466628.levitte@openssl.org> <20151115211623.GD18315@mournblade.imrryr.org> Message-ID: <5649168E.7020202@openssl.org> On 15/11/15 21:16, Viktor Dukhovni wrote: > Is the pain worth the gain? I'm inclined to think that dropping > TLS ciphersuite code points, and assembly support, is a rather > sensible first step. I agree with this. I am wary of dropping too much too quickly. Matt From weber at infotech.de Mon Nov 16 12:14:52 2015 From: weber at infotech.de (weber at infotech.de) Date: Mon, 16 Nov 2015 13:14:52 +0100 Subject: [openssl-dev] certificate signing using rsa pss algorithm? In-Reply-To: <1447350343896.514603.f5a18b4fe531dff171f3dbb8d59cc7bb16f7f803@spica.telekom.de> References: <5642235A.4020500@infotech.de> <1447350343896.514603.f5a18b4fe531dff171f3dbb8d59cc7bb16f7f803@spica.telekom.de> Message-ID: <5649C8BC.3040908@infotech.de> Thanks for your reply. Am 12.11.2015 um 18:45 schrieb Stefan.Neis at t-online.de: > Hi, > > You might want to upgrade to OpenSSL-1.0.2 which seems to support the > RSA PSS algorithm, see https://openssl.org/news/changelog.html#x5. > > Regards, > Stefan ... we are up to the most current version, i.e. Snippet OpenSSL 1.0.2d 9 Jul 2015. Trying the commandline tool > openssl req -new -x509 -nodes -sha256 -days 365 -newkey rsa:2048 -out > rca.pubcert.pem -keyout rca.privkey.pem -pkeyopt rsa_padding_mode:pss > -pkeyopt rsa_pss_saltlen:-2 -passin pass: ... leads to ... > Loading 'screen' into random state - done > parameter error "rsa_padding_mode:pss" > 10584:error:0408F090:rsa routines:PKEY_RSA_CTRL:illegal or unsupported > padding mode:.\crypto\rsa\rsa_pmeth.c:517: > 10584:error:06089093:digital envelope > routines:EVP_PKEY_CTX_ctrl:command not > supported:.\crypto\evp\pmeth_lib.c:405: ... Since we found explicit exclusion of PSS padding for cert signing in .\crypto\rsa\rsa_pmeth.c:501, we guess PSS signing of certificates is currently not officially supported. So we've just asked for the reason why, since we're looking for certificates which may satisfy security needs for decades. Regards -- Christian Weber From hkario at redhat.com Mon Nov 16 13:21:47 2015 From: hkario at redhat.com (Hubert Kario) Date: Mon, 16 Nov 2015 14:21:47 +0100 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: Message-ID: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> On Friday 13 November 2015 14:40:33 Emilia K?sper wrote: > Hi all, > > We are considering removing from OpenSSL 1.1 known broken or outdated > cryptographic primitives. As you may know the forks have already done > this but I'd like to seek careful feedback for OpenSSL first to > ensure we won't be breaking any major applications. > > These algorithms are currently candidates for removal: > > CAST > IDEA > MDC2 > MD2 [ already disabled by default ] > RC5 [ already disabled by default ] > RIPEMD > SEED > WHIRLPOOL > ALL BINARY ELLIPTIC CURVES > > My preference would be to remove these algorithms completely (as in, > delete the code). Disabled-by-default code will either be re-enabled > by distros (if there's widespread need for it - in which case we > might as well leave it in) or will be poorly tested and is likely to > just silently rot and break. This code is bloat and maintentance > burden for us - my hope is that much of this code is effectively dead > and can be removed. > > *Are you aware of any mainstream need to continue supporting these > algorithms in OpenSSL 1.1?* Note that an older OpenSSL library or > binary, or a standalone implementation or another crypto toolkit can > always be used to continue supporting a legacy standalone > application, or to decrypt ciphertext from the distant past. I am > looking for use cases that could cause e.g. interop breakage between > new and old peers, or major pain to distro end-users. > > These algorithms are obsolete but removing them doesn't look feasible: > > BLOWFISH - probably still in use though I don't know where exactly? > MD4 - used in NTLM > RC2 - used in PKCS#12 > > *Did I miss anything from the list?* I'd say that this is the wrong approach. If you have old stuff signed with MD2, and then timestamped with MD5, SHA-1, SHA-256 over the years, with new timestamp added every year this makes the MD2 signature _valid_ and _secure_. If you have stuff that is encrypted, but in deep storage with any of those algorithms, then yes, it's less than optimal. Removing support for those algorithm will make this data inaccessible. Not to mention that stuff like IDEA or SEED may never get broken before the data in them needs to remain secret - and after that creating a new archive with unencrypted data after it can become public would simply cost money. And as some pointed out, few OpenSSL users actually read mailing lists, fewer still know what actual primitives are necessary for their stuff to work (e.g. PKCS#8 files specify inside them the cipher and key derivation necessary for decryption). What I think is the correct course of action, is to have in the configuration file settings which specify the set of algorithms that are set as available and trusted. So that we can disable them by default and require the users to make a concious decision to enable support for them. (Make openssl print to stderr info about them being administratively disabled when application tries using them for bonus points). This allows to place the information about this depreciation in a place where users will actually see it and will make them concious of using weak and badly tested algorithms. At the same time it will protect most of the users that don't require such obsolete algorithms. But this concious decision MUST NOT require recompilation of the package. Few if any distributions support recompiled packages. For many end-users this is also a hurdle they simply can't cross. And this also allows openssl to change the cryptographic policy in stable branches without breaking the API/ABI promise. (POODLE, FREAK, Logjam) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rt at openssl.org Mon Nov 16 14:22:25 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Mon, 16 Nov 2015 14:22:25 +0000 Subject: [openssl-dev] [openssl.org #4141] GOST ciphersuites In-Reply-To: References: Message-ID: On Sun Nov 15 10:04:28 2015, beldmit at gmail.com wrote: > Hello! > > In the commit 5e3d21fef150f020e2d33439401da8f7e311aa24 you set > the SSL_SSLV3 for the GOST ciphersuites. But the GOST ciphersuites are not > usable with SSLv3, they require TLSv1. > > Could you turn the flag back for the GOST ciphersuites? > Does that commit break anything? It should not change the previous functionality in any way because we also had this in ssl_locl.h: # define SSL_TLSV1 SSL_SSLV3/* for now */ The subsequent commits change SSL_TLSV1 so it really disables ciphersuites in SSL v3 (before it didn't) and adds the flag to PSK+SHA2 ciphersuites, We can add SSL_TLSV1 to the GOST ciphersuites but that will change the behaviour from what it was before. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From emilia at openssl.org Mon Nov 16 15:51:10 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Mon, 16 Nov 2015 16:51:10 +0100 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> Message-ID: Thanks all for your feedback! I asked for mainstream use-cases for algorithms whose removal could cause widespread pain. Some individual users, undoubtedly, will be hit by this, and I acknowledge that they may not be reading this list. But I wanted to know if I'd missed something endemic. I also asked elsewhere: Adam Langley pointed me to the MD4 use-case and Steve confirmed that RC2 must stay. There is a tradeoff: by attempting to accommodate every single use-case, we will weaken the library for a substantial amount of our user base, by offering them bad defaults, or simply by virtue of the fact that our developer resources are not infinite. (Near)-dead code is a liability. So far, excluding suspicions that something may be used somewhere, I've received one clear argument, for RC5. And, while I'm sympathetic to the cause, I believe this is the case where we have to balance one user's needs against everyone else's. As for specific deprecation strategies: - Don't forget that all applications will have to recompile against 1.1. - Disabling algorithms doesn't work well for us as it's just pushing the decision on the distros. It also wouldn't win us any resources as we'd still be responsible for keeping the code bug-free. The only win would be in default compiled code size. - We can leave OPENSSL_NO_XXX defines around so wrapper libraries (Python, PHP etc) who correctly account for the fact that an implementation may be missing (which they have to, anyway) will continue to work. - Removing assembly support is a GREAT suggestion to simplify the complexity, and I think we should do this for anything we end up leaving in, and perhaps even for some things not yet on the hit list (RC4?). - I appreciate OpenSSL's role as a "Swiss army knife" research tool but research needs shouldn't prevail over those of real applications. We are generally not on the frontline of deprecating things - RC4 isn't yet on the list. SSLv3 isn't yet on the list, etc. But we can't become the Internet Archive of All Old Crypto either, and there's some cleanup to do that's long overdue. - I believe that the OpenSSL community generally tends to overlook the positive impact of change when trying to round up the negative impact of breakage. Applications are generally able to move along and fix things when presented with the right incentives. Applications that aren't generally able to move along are rather unlikely to jump onto OpenSSL 1.1, and all these algorithms will be supported as part of OpenSSL 1.0.2 until 2020 for them. Finally, removing support for these algorithms from OpenSSL doesn't render your encrypted storage inaccessible. You can always use another implementation to decrypt/re-encrypt your data, and I fully believe in the power of the community in providing such tools where necessary. - Recent anecdotal evidence: OpenSSL's Logjam protection caused pretty widespread MySQL breakage. That made MySQL backport a change increasing the DH key length from 512 to 2048 bits. For end user security, it's a win. I would prefer that we start cashing in these improvements before the next Logjam happens. (This is my view; as you can see views differ even within the team.) - On binary elliptic curves: with recent cryptographic advances, I believe these are now firmly planted in the "internet archive" category, even if not practically broken yet. The other reason for removing these is that our implementations are crappy. They're not constant-time, and they've been shown to contain bugs. Improving upon these implementations is not a good use of dev time imo, given their decreasing credibility. Here's the list of algorithms gone from BoringSSL: IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves This isn't of course entirely representative of widespread usage. However Google's multi-billion line codebase now builds against BoringSSL and therefore largely does not depend on these algorithms. Those billions of lines aren't all new and shiny code written in 2015, and some of it does have to interoperate with the outside world. And here's the list gone from LibreSSL, from what I can tell: MD2, MDC2, RC5, SEED Neither have removed CAST, and there is presumably a good reason for that. (PGP?) It seems to me that these can pretty safely go: MD2 - (The argument that someone somewhere may want to keep verifying old MD2 signatures on self-signed certs doesn't seem like a compelling enough reason to me. It's been disabled by default since OpenSSL 1.0.0.) MDC2 SEED RC5 These could probably stay (C only): CAST IDEA RIPEMD (used in Bitcoin?) WHIRLPOOL as well as BLOWFISH MD4 RC2 I am on the fence about the binary curves: I am not aware of any usage, really, and it's not about to pick up now. Cheers, Emilia On Mon, Nov 16, 2015 at 2:21 PM, Hubert Kario wrote: > On Friday 13 November 2015 14:40:33 Emilia K?sper wrote: > > Hi all, > > > > We are considering removing from OpenSSL 1.1 known broken or outdated > > cryptographic primitives. As you may know the forks have already done > > this but I'd like to seek careful feedback for OpenSSL first to > > ensure we won't be breaking any major applications. > > > > These algorithms are currently candidates for removal: > > > > CAST > > IDEA > > MDC2 > > MD2 [ already disabled by default ] > > RC5 [ already disabled by default ] > > RIPEMD > > SEED > > WHIRLPOOL > > ALL BINARY ELLIPTIC CURVES > > > > My preference would be to remove these algorithms completely (as in, > > delete the code). Disabled-by-default code will either be re-enabled > > by distros (if there's widespread need for it - in which case we > > might as well leave it in) or will be poorly tested and is likely to > > just silently rot and break. This code is bloat and maintentance > > burden for us - my hope is that much of this code is effectively dead > > and can be removed. > > > > *Are you aware of any mainstream need to continue supporting these > > algorithms in OpenSSL 1.1?* Note that an older OpenSSL library or > > binary, or a standalone implementation or another crypto toolkit can > > always be used to continue supporting a legacy standalone > > application, or to decrypt ciphertext from the distant past. I am > > looking for use cases that could cause e.g. interop breakage between > > new and old peers, or major pain to distro end-users. > > > > These algorithms are obsolete but removing them doesn't look feasible: > > > > BLOWFISH - probably still in use though I don't know where exactly? > > MD4 - used in NTLM > > RC2 - used in PKCS#12 > > > > *Did I miss anything from the list?* > > I'd say that this is the wrong approach. > > If you have old stuff signed with MD2, and then timestamped with MD5, > SHA-1, SHA-256 over the years, with new timestamp added every year this > makes the MD2 signature _valid_ and _secure_. > > If you have stuff that is encrypted, but in deep storage with any of > those algorithms, then yes, it's less than optimal. Removing support for > those algorithm will make this data inaccessible. Not to mention that > stuff like IDEA or SEED may never get broken before the data in them > needs to remain secret - and after that creating a new archive with > unencrypted data after it can become public would simply cost money. > > And as some pointed out, few OpenSSL users actually read mailing lists, > fewer still know what actual primitives are necessary for their stuff to > work (e.g. PKCS#8 files specify inside them the cipher and key > derivation necessary for decryption). > > > What I think is the correct course of action, is to have in the > configuration file settings which specify the set of algorithms that are > set as available and trusted. So that we can disable them by default and > require the users to make a concious decision to enable support for > them. (Make openssl print to stderr info about them being > administratively disabled when application tries using them for bonus > points). > > This allows to place the information about this depreciation in a place > where users will actually see it and will make them concious of using > weak and badly tested algorithms. At the same time it will protect most > of the users that don't require such obsolete algorithms. > > But this concious decision MUST NOT require recompilation of the > package. Few if any distributions support recompiled packages. For many > end-users this is also a hurdle they simply can't cross. > > And this also allows openssl to change the cryptographic policy in > stable branches without breaking the API/ABI promise. (POODLE, FREAK, > Logjam) > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Nov 16 16:09:28 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 16 Nov 2015 16:09:28 +0000 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> Message-ID: <20151116160928.GK18315@mournblade.imrryr.org> On Mon, Nov 16, 2015 at 04:51:10PM +0100, Emilia K?sper wrote: > As for specific deprecation strategies: > - Don't forget that all applications will have to recompile against 1.1. The EVP_get_cipherbyname() and EVP_get_digestbyname() interfaces remain, so nothing changes at compile-time. Most code does not use EVP_() directly. This means that: * Most errors are not caught at compile time. * Porting is not the difficult part, the much more difficult problem is dealing with runtime access to any algorithms needed to handle data at rest. > - Disabling algorithms doesn't work well for us as it's just pushing the > decision on the distros. It also wouldn't win us any resources as we'd > still be responsible for keeping the code bug-free. The only win would be > in default compiled code size. Removing assembly support would substantially lower support cost. For many of the algorithms we can likely find a reference implementation in an RFC or similar standards document, if our own code is substantially more refined (and requires greater support effort). > - We can leave OPENSSL_NO_XXX defines around so wrapper libraries (Python, > PHP etc) who correctly account for the fact that an implementation may be > missing (which they have to, anyway) will continue to work. These don't help with EVP "by name" indirection. > - Removing assembly support is a GREAT suggestion to simplify the > complexity, and I think we should do this for anything we end up leaving > in, and perhaps even for some things not yet on the hit list (RC4?). Yes, and probably. > - I appreciate OpenSSL's role as a "Swiss army knife" research tool but > research needs shouldn't prevail over those of real applications. We are > generally not on the frontline of deprecating things - RC4 isn't yet on the > list. SSLv3 isn't yet on the list, etc. But we can't become the Internet > Archive of All Old Crypto either, and there's some cleanup to do that's > long overdue. Researchers can indeed use older toolkits, my concern is real users, with non-SSL applications (data at rest). > - Recent anecdotal evidence: OpenSSL's Logjam protection caused pretty > widespread MySQL breakage. That made MySQL backport a change increasing the > DH key length from 512 to 2048 bits. For end user security, it's a win. I > would prefer that we start cashing in these improvements before the next > Logjam happens. (This is my view; as you can see views differ even within > the team.) This is SSL/TLS where we have algorithm agility. I support the Logjam changes. It is likely time for us to take the next (not final) step from 768 to 1024 as the min prime size. > - On binary elliptic curves: with recent cryptographic advances, I believe > these are now firmly planted in the "internet archive" category, even if > not practically broken yet. The other reason for removing these is that our > implementations are crappy. They're not constant-time, and they've been > shown to contain bugs. Improving upon these implementations is not a good > use of dev time imo, given their decreasing credibility. I agree they need to go from SSL/TLS. What about S/MIME and CMS? > Here's the list of algorithms gone from BoringSSL: > > IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves Boring SSL has a very narrow user base. By all means drop as much as you can get away with. > And here's the list gone from LibreSSL, from what I can tell: > > MD2, MDC2, RC5, SEED Likewise, not a wide user base. We can make incremental steps, drop assembly support and SSL/TLS codepoints in this release, and assess things from there. My hope is that the support cost of a stable reference implementation in C (yes, likely not constant time) is not that onerous. -- Viktor. From hkario at redhat.com Mon Nov 16 18:25:07 2015 From: hkario at redhat.com (Hubert Kario) Date: Mon, 16 Nov 2015 19:25:07 +0100 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> Message-ID: <16838026.jLb3FpZjMu@pintsize.usersys.redhat.com> On Monday 16 November 2015 16:51:10 Emilia K?sper wrote: > IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves > > This isn't of course entirely representative of widespread usage. > However Google's multi-billion line codebase now builds against > BoringSSL and therefore largely does not depend on these algorithms. > Those billions of lines aren't all new and shiny code written in > 2015, and some of it does have to interoperate with the outside > world. > > And here's the list gone from LibreSSL, from what I can tell: > > MD2, MDC2, RC5, SEED > > Neither have removed CAST, and there is presumably a good reason for > that. (PGP?) > > It seems to me that these can pretty safely go: > > MD2 - (The argument that someone somewhere may want to keep verifying > old MD2 signatures on self-signed certs doesn't seem like a > compelling enough reason to me. It's been disabled by default since > OpenSSL 1.0.0.) MDC2 > SEED > RC5 > > These could probably stay (C only): > > CAST > IDEA > RIPEMD (used in Bitcoin?) > WHIRLPOOL > > as well as > > BLOWFISH > MD4 > RC2 > > I am on the fence about the binary curves: I am not aware of any > usage, really, and it's not about to pick up now. I'm afraid you're too focused on TLS/SSL use case. And while it is important it's not the only use case the OpenSSL does serve. And for what it's worth, I'm very much *for* removing as much (and as fast as possible) support for the old junk (or unused stuff - like curves < 256 bit) in TLS. Search the archives for "Insecure DEFAULT cipher set" for an example. But stuff like this: > The argument that someone somewhere may want to keep verifying > old MD2 signatures on self-signed certs is not true. I was talking about document signatures, time stamps, CRL signatures and certificate signatures in general. Not the trust anchors or their self-signatures. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From emilia at openssl.org Mon Nov 16 18:51:08 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Mon, 16 Nov 2015 19:51:08 +0100 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <16838026.jLb3FpZjMu@pintsize.usersys.redhat.com> References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> <16838026.jLb3FpZjMu@pintsize.usersys.redhat.com> Message-ID: One more time, I know that someone, somewhere is probably using any given feature of OpenSSL. I am looking to gather information about concrete, actively maintained applications that may be using one of those algorithms, to build a more complete picture. If you are aware of a concrete use of MD2 or any of the other algorithms, please let us know! Thanks, Emilia On Mon, Nov 16, 2015 at 7:25 PM, Hubert Kario wrote: > On Monday 16 November 2015 16:51:10 Emilia K?sper wrote: > > IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves > > > > This isn't of course entirely representative of widespread usage. > > However Google's multi-billion line codebase now builds against > > BoringSSL and therefore largely does not depend on these algorithms. > > Those billions of lines aren't all new and shiny code written in > > 2015, and some of it does have to interoperate with the outside > > world. > > > > And here's the list gone from LibreSSL, from what I can tell: > > > > MD2, MDC2, RC5, SEED > > > > Neither have removed CAST, and there is presumably a good reason for > > that. (PGP?) > > > > It seems to me that these can pretty safely go: > > > > MD2 - (The argument that someone somewhere may want to keep verifying > > old MD2 signatures on self-signed certs doesn't seem like a > > compelling enough reason to me. It's been disabled by default since > > OpenSSL 1.0.0.) MDC2 > > SEED > > RC5 > > > > These could probably stay (C only): > > > > CAST > > IDEA > > RIPEMD (used in Bitcoin?) > > WHIRLPOOL > > > > as well as > > > > BLOWFISH > > MD4 > > RC2 > > > > I am on the fence about the binary curves: I am not aware of any > > usage, really, and it's not about to pick up now. > > I'm afraid you're too focused on TLS/SSL use case. And while it is > important it's not the only use case the OpenSSL does serve. > > And for what it's worth, I'm very much *for* removing as much (and as > fast as possible) support for the old junk (or unused stuff - like > curves < 256 bit) in TLS. Search the archives for "Insecure DEFAULT > cipher set" for an example. > > But stuff like this: > > > The argument that someone somewhere may want to keep verifying > > old MD2 signatures on self-signed certs > > is not true. I was talking about document signatures, time stamps, CRL > signatures and certificate signatures in general. Not the trust anchors > or their self-signatures. > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hkario at redhat.com Mon Nov 16 19:05:44 2015 From: hkario at redhat.com (Hubert Kario) Date: Mon, 16 Nov 2015 20:05:44 +0100 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <16838026.jLb3FpZjMu@pintsize.usersys.redhat.com> Message-ID: <2923076.EjhxOnJbK2@pintsize.usersys.redhat.com> On Monday 16 November 2015 19:51:08 Emilia K?sper wrote: > One more time, > > I know that someone, somewhere is probably using any given feature of > OpenSSL. I am looking to gather information about concrete, actively > maintained applications that may be using one of those algorithms, to > build a more complete picture. > > If you are aware of a concrete use of MD2 or any of the other > algorithms, please let us know! And I'm saying that it is next-to impossible for me to say for certain because standards like CMS, S/MIME, PKCS#8 and X.509 are extensible and self descriptive. The file itself says which algorithms are needed to process it. So without access to _all_ _data_ that the applications need to process it is impossible for me to tell which of those algorithms are necessary for continued operation of those applications. Example: CAdES V1.2.2 was published in late 2000, the first serious attacks on MD2 were not published until 2004. I think it is not unreasonable for CAdES-A documents to exist today which were originally signed with MD2 while it was still considered secure and that are still relevant today, just 15 years later. > Thanks, > Emilia > > On Mon, Nov 16, 2015 at 7:25 PM, Hubert Kario wrote: > > On Monday 16 November 2015 16:51:10 Emilia K?sper wrote: > > > IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves > > > > > > This isn't of course entirely representative of widespread usage. > > > However Google's multi-billion line codebase now builds against > > > BoringSSL and therefore largely does not depend on these > > > algorithms. > > > Those billions of lines aren't all new and shiny code written in > > > 2015, and some of it does have to interoperate with the outside > > > world. > > > > > > And here's the list gone from LibreSSL, from what I can tell: > > > > > > MD2, MDC2, RC5, SEED > > > > > > Neither have removed CAST, and there is presumably a good reason > > > for > > > that. (PGP?) > > > > > > It seems to me that these can pretty safely go: > > > > > > MD2 - (The argument that someone somewhere may want to keep > > > verifying > > > old MD2 signatures on self-signed certs doesn't seem like a > > > compelling enough reason to me. It's been disabled by default > > > since > > > OpenSSL 1.0.0.) MDC2 > > > SEED > > > RC5 > > > > > > These could probably stay (C only): > > > > > > CAST > > > IDEA > > > RIPEMD (used in Bitcoin?) > > > WHIRLPOOL > > > > > > as well as > > > > > > BLOWFISH > > > MD4 > > > RC2 > > > > > > I am on the fence about the binary curves: I am not aware of any > > > usage, really, and it's not about to pick up now. > > > > I'm afraid you're too focused on TLS/SSL use case. And while it is > > important it's not the only use case the OpenSSL does serve. > > > > And for what it's worth, I'm very much *for* removing as much (and > > as > > fast as possible) support for the old junk (or unused stuff - like > > curves < 256 bit) in TLS. Search the archives for "Insecure DEFAULT > > cipher set" for an example. > > > > But stuff like this: > > > The argument that someone somewhere may want to keep verifying > > > old MD2 signatures on self-signed certs > > > > is not true. I was talking about document signatures, time stamps, > > CRL signatures and certificate signatures in general. Not the trust > > anchors or their self-signatures. > > > > -- > > Regards, > > Hubert Kario > > Senior Quality Engineer, QE BaseOS Security team > > Web: www.cz.redhat.com > > Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From richmoore44 at gmail.com Mon Nov 16 20:28:01 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Mon, 16 Nov 2015 20:28:01 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <2923076.EjhxOnJbK2@pintsize.usersys.redhat.com> References: <16838026.jLb3FpZjMu@pintsize.usersys.redhat.com> <2923076.EjhxOnJbK2@pintsize.usersys.redhat.com> Message-ID: On 16 November 2015 at 19:05, Hubert Kario wrote: > Example: CAdES V1.2.2 was published in late 2000, the first serious > attacks on MD2 were not published until 2004. I think it is not > unreasonable for CAdES-A documents to exist today which were originally > signed with MD2 while it was still considered secure and that are still > relevant today, just 15 years later. > > ?This doesn't explain why the code needs to exist in future versions of openssl. The previous ones aren't going to vanish and can be compiled and used to rescue data in theoretical edge cases like this. You're making it sound like this is making the data totally inaccessible which is not the case. Cheers Rich.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Mon Nov 16 20:33:34 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 16 Nov 2015 23:33:34 +0300 Subject: [openssl-dev] [openssl.org #4141] GOST ciphersuites In-Reply-To: References: Message-ID: Dear Stephen, On Mon, Nov 16, 2015 at 5:22 PM, Stephen Henson via RT wrote: > On Sun Nov 15 10:04:28 2015, beldmit at gmail.com wrote: > > Hello! > > > > In the commit 5e3d21fef150f020e2d33439401da8f7e311aa24 you set > > the SSL_SSLV3 for the GOST ciphersuites. But the GOST ciphersuites are > not > > usable with SSLv3, they require TLSv1. > > > > Could you turn the flag back for the GOST ciphersuites? > > > > Does that commit break anything? It should not change the previous > functionality in any way because we also had this in ssl_locl.h: > No, it does not break our tests. > > # define SSL_TLSV1 SSL_SSLV3/* for now */ > > The subsequent commits change SSL_TLSV1 so it really disables ciphersuites > in > SSL v3 (before it didn't) and adds the flag to PSK+SHA2 ciphersuites, We > can > add SSL_TLSV1 to the GOST ciphersuites but that will change the behaviour > from > what it was before. > Usage of the GOST ciphersuites with the SSLv3 protocol is not specified, so the change should not affect the GOST-related behaviour. So I think it will be better for clarity. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Nov 16 20:33:48 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Mon, 16 Nov 2015 20:33:48 +0000 Subject: [openssl-dev] [openssl.org #4141] GOST ciphersuites In-Reply-To: References: Message-ID: Dear Stephen, On Mon, Nov 16, 2015 at 5:22 PM, Stephen Henson via RT wrote: > On Sun Nov 15 10:04:28 2015, beldmit at gmail.com wrote: > > Hello! > > > > In the commit 5e3d21fef150f020e2d33439401da8f7e311aa24 you set > > the SSL_SSLV3 for the GOST ciphersuites. But the GOST ciphersuites are > not > > usable with SSLv3, they require TLSv1. > > > > Could you turn the flag back for the GOST ciphersuites? > > > > Does that commit break anything? It should not change the previous > functionality in any way because we also had this in ssl_locl.h: > No, it does not break our tests. > > # define SSL_TLSV1 SSL_SSLV3/* for now */ > > The subsequent commits change SSL_TLSV1 so it really disables ciphersuites > in > SSL v3 (before it didn't) and adds the flag to PSK+SHA2 ciphersuites, We > can > add SSL_TLSV1 to the GOST ciphersuites but that will change the behaviour > from > what it was before. > Usage of the GOST ciphersuites with the SSLv3 protocol is not specified, so the change should not affect the GOST-related behaviour. So I think it will be better for clarity. Thank you! -- SY, Dmitry Belyavsky From uri at ll.mit.edu Mon Nov 16 20:37:23 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 16 Nov 2015 20:37:23 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <16838026.jLb3FpZjMu@pintsize.usersys.redhat.com> <2923076.EjhxOnJbK2@pintsize.usersys.redhat.com> Message-ID: > On 16 November 2015 at 19:05, Hubert Kario wrote: >> Example: CAdES V1.2.2 was published in late 2000, the first serious >> attacks on MD2 were not published until 2004. I think it is not >> unreasonable for CAdES-A documents to exist today which were originally >> signed with MD2 while it was still considered secure and that are still >> relevant today, just 15 years later. > > ?This doesn't explain why the code needs to exist in future versions of > openssl. The previous ones aren't going to vanish and can be compiled and used > to rescue data in theoretical edge cases like this. You're making it sound > like this is making the data totally inaccessible which is not the case. Of course people can keep the current OpenSSL version indefinitely ? and if the maintainers are too aggressive, it might just happen. But the vast majority of the uses would like to upgrade to new releases with hopefully more bugs fixed and fewer bugs introduced ? and maintain their current functionality. Because if the new version stops decrypting their documents, who needs it? Several people pointed out: SSL/TLS is where the algorithm agility is, where the exploits are, and what needs to be pruned. So remove the dead wood from libssl. Leave libcrypto alone ? it is useful as-is, and real-life big packages (like Perl) depend on it providing all the services it currently offers. Don?t punish users for choosing OpenSSL library to handle their non-SSL cryptographic needs and implicitly trusting the developers that they won?t be left in the cold. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From pwalten at au1.ibm.com Mon Nov 16 21:58:36 2015 From: pwalten at au1.ibm.com (Peter Waltenberg) Date: Tue, 17 Nov 2015 07:58:36 +1000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <16838026.jLb3FpZjMu@pintsize.usersys.redhat.com> <2923076.EjhxOnJbK2@pintsize.usersys.redhat.com> Message-ID: <201511162200.tAGM0pBU001010@d23av06.au.ibm.com> The reason for keeping the old crypto. algorithms around is the obvious one, that's been stated over and over. OpenSSL's SSL isn't the only consumer of the algorithms, remove the low level algorithms and you risk breaking more than OpenSSL. SSH, IKE,IPSec, Kerberos and I'm sure there are more, and the scripting languages like Perl that use OpenSSL to provide algorithm support. There are a lot of ecosystems built on top of OpenSSL's crypto, it's not just SSL, and for someone like a distro. maintainer it's between a rock and a hard place, stick with the old code and patch the security vulnerabilities, or break stuff. Which is why them being still available in the old code isn't a good enough answer to the problems this would create. And in this case 'breaking stuff' is unecessary. Do what you like with TLS in terms of pruning algorithms in use, but removing the algorithms is a lot like burning books in a library for being irrelevant. They may be irrelevant to you, but they aren't necessarilly irrelevant to everyone. Peter From: Richard Moore To: openssl-dev at openssl.org Cc: openssl-users at openssl.org Date: 17/11/2015 06:29 Subject: Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback Sent by: "openssl-dev" On 16 November 2015 at 19:05, Hubert Kario wrote: Example: CAdES V1.2.2 was published in late 2000, the first serious attacks on MD2 were not published until 2004. I think it is not unreasonable for CAdES-A documents to exist today which were originally signed with MD2 while it was still considered secure and that are still relevant today, just 15 years later. ?This doesn't explain why the code needs to exist in future versions of openssl. The previous ones aren't going to vanish and can be compiled and used to rescue data in theoretical edge cases like this. You're making it sound like this is making the data totally inaccessible which is not the case. Cheers Rich.??_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From matt at openssl.org Mon Nov 16 23:23:52 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 16 Nov 2015 23:23:52 +0000 Subject: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <564A653E.8000000@openssl.org> References: <564A653E.8000000@openssl.org> Message-ID: <564A6588.9090908@openssl.org> Meant to send this to openssl-dev not openssl-users so resending... On 16/11/15 15:51, Emilia K?sper wrote: > Thanks all for your feedback! > > I asked for mainstream use-cases for algorithms whose removal could > cause widespread pain. Some individual users, undoubtedly, will be hit > by this, and I acknowledge that they may not be reading this list. But I > wanted to know if I'd missed something endemic. I also asked elsewhere: > Adam Langley pointed me to the MD4 use-case and Steve confirmed that RC2 > must stay. > > There is a tradeoff: by attempting to accommodate every single use-case, > we will weaken the library for a substantial amount of our user base, by > offering them bad defaults, or simply by virtue of the fact that our > developer resources are not infinite. (Near)-dead code is a liability. We can significantly reduce that liability by removing any assembler optimisations. Also just because something is available doesn't mean it has to be "default". We can have good defaults whilst keeping old crypto. > > So far, excluding suspicions that something may be used somewhere, I've > received one clear argument, for RC5. And, while I'm sympathetic to the > cause, I believe this is the case where we have to balance one user's > needs against everyone else's. > > As for specific deprecation strategies: > - Don't forget that all applications will have to recompile against 1.1. > > - Disabling algorithms doesn't work well for us as it's just pushing the > decision on the distros. It also wouldn't win us any resources as we'd > still be responsible for keeping the code bug-free. The only win would > be in default compiled code size. Disabling algorithms isn't the right answer IMO. I do like the idea of a "liblegacycrypto". That way people that only have need of current up-to-date crypto can stick with the main library. Others who need the older crypto can still get at it. Yes, that means we still have to maintain this code - but I don't see it as that big a burden. > > - We can leave OPENSSL_NO_XXX defines around so wrapper libraries > (Python, PHP etc) who correctly account for the fact that an > implementation may be missing (which they have to, anyway) will continue > to work. > > - Removing assembly support is a GREAT suggestion to simplify the > complexity, and I think we should do this for anything we end up leaving > in, and perhaps even for some things not yet on the hit list (RC4?). > > - I appreciate OpenSSL's role as a "Swiss army knife" research tool but > research needs shouldn't prevail over those of real applications. We are > generally not on the frontline of deprecating things - RC4 isn't yet on > the list. SSLv3 isn't yet on the list, etc. But we can't become the > Internet Archive of All Old Crypto either, and there's some cleanup to > do that's long overdue. Being the "swiss army knife" is no bad thing (even where that includes old crypto). We just have to find a way to separate the two concerns: current crypto (and only current crypto) for most (and probably most importantly for libssl users); broader crypto support for those that want it (which is why I like the liblegacycrypto idea because it enables us to do that). > It seems to me that these can pretty safely go: > > MD2 - (The argument that someone somewhere may want to keep verifying > old MD2 signatures on self-signed certs doesn't seem like a compelling > enough reason to me. It's been disabled by default since OpenSSL 1.0.0.) > MDC2 > SEED > RC5 All candidates for liblegacycrypto IMO rather than deletion. Whether this is the right thing to do in the 1.1.0 timeframe is another consideration though. Viktor's arguments are quite convincing. Matt From uri at ll.mit.edu Mon Nov 16 23:40:20 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 16 Nov 2015 23:40:20 +0000 Subject: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <564A6588.9090908@openssl.org> References: <564A653E.8000000@openssl.org> <564A6588.9090908@openssl.org> Message-ID: Huge +1. I find Viktor?s arguments more than convincing - irrefutable. As for ?weakening the library?, I don?t find this argument correct. It is not about libssl - it?s about libcrypto. Quite a different animal. -- Regards, Uri Blumenthal On 11/16/15, 18:23 , "openssl-dev on behalf of Matt Caswell" wrote: > >Meant to send this to openssl-dev not openssl-users so resending... > >On 16/11/15 15:51, Emilia K?sper wrote: >> Thanks all for your feedback! >> >> I asked for mainstream use-cases for algorithms whose removal could >> cause widespread pain. Some individual users, undoubtedly, will be hit >> by this, and I acknowledge that they may not be reading this list. But I >> wanted to know if I'd missed something endemic. I also asked elsewhere: >> Adam Langley pointed me to the MD4 use-case and Steve confirmed that RC2 >> must stay. >> >> There is a tradeoff: by attempting to accommodate every single use-case, >> we will weaken the library for a substantial amount of our user base, by >> offering them bad defaults, or simply by virtue of the fact that our >> developer resources are not infinite. (Near)-dead code is a liability. > >We can significantly reduce that liability by removing any assembler >optimisations. Also just because something is available doesn't mean it >has to be "default". We can have good defaults whilst keeping old crypto. > > >> >> So far, excluding suspicions that something may be used somewhere, I've >> received one clear argument, for RC5. And, while I'm sympathetic to the >> cause, I believe this is the case where we have to balance one user's >> needs against everyone else's. >> >> As for specific deprecation strategies: >> - Don't forget that all applications will have to recompile against 1.1. >> >> - Disabling algorithms doesn't work well for us as it's just pushing the >> decision on the distros. It also wouldn't win us any resources as we'd >> still be responsible for keeping the code bug-free. The only win would >> be in default compiled code size. > >Disabling algorithms isn't the right answer IMO. I do like the idea of a >"liblegacycrypto". That way people that only have need of current >up-to-date crypto can stick with the main library. Others who need the >older crypto can still get at it. Yes, that means we still have to >maintain this code - but I don't see it as that big a burden. > >> >> - We can leave OPENSSL_NO_XXX defines around so wrapper libraries >> (Python, PHP etc) who correctly account for the fact that an >> implementation may be missing (which they have to, anyway) will continue >> to work. >> >> - Removing assembly support is a GREAT suggestion to simplify the >> complexity, and I think we should do this for anything we end up leaving >> in, and perhaps even for some things not yet on the hit list (RC4?). >> >> - I appreciate OpenSSL's role as a "Swiss army knife" research tool but >> research needs shouldn't prevail over those of real applications. We are >> generally not on the frontline of deprecating things - RC4 isn't yet on >> the list. SSLv3 isn't yet on the list, etc. But we can't become the >> Internet Archive of All Old Crypto either, and there's some cleanup to >> do that's long overdue. > >Being the "swiss army knife" is no bad thing (even where that includes >old crypto). We just have to find a way to separate the two concerns: >current crypto (and only current crypto) for most (and probably most >importantly for libssl users); broader crypto support for those that >want it (which is why I like the liblegacycrypto idea because it enables >us to do that). > > >> It seems to me that these can pretty safely go: >> >> MD2 - (The argument that someone somewhere may want to keep verifying >> old MD2 signatures on self-signed certs doesn't seem like a compelling >> enough reason to me. It's been disabled by default since OpenSSL 1.0.0.) >> MDC2 >> SEED >> RC5 > >All candidates for liblegacycrypto IMO rather than deletion. > >Whether this is the right thing to do in the 1.1.0 timeframe is another >consideration though. Viktor's arguments are quite convincing. > >Matt > > >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From openssl-users at dukhovni.org Tue Nov 17 00:01:09 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 17 Nov 2015 00:01:09 +0000 Subject: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <564A6588.9090908@openssl.org> References: <564A653E.8000000@openssl.org> <564A6588.9090908@openssl.org> Message-ID: <20151117000109.GS18315@mournblade.imrryr.org> On Mon, Nov 16, 2015 at 11:23:52PM +0000, Matt Caswell wrote: > Disabling algorithms isn't the right answer IMO. I do like the idea of a > "liblegacycrypto". That way people that only have need of current > up-to-date crypto can stick with the main library. Others who need the > older crypto can still get at it. Yes, that means we still have to > maintain this code - but I don't see it as that big a burden. What becomes a bit tricky is having an EVP interface that can find the algorithms in liblegacrypto. This I think means two different builds of the crypto library, one that depends on liblegacycrypto and provides its algorithms, and another than does not. Systems might then ship with: libcrypto-legacy.so - Just the legacy algorithms libcrypto-compat.so - Libcrypto that supports the above libcrypto-secure.so - Libcrypto with just the strong algos libcrypto.so - Symlink to one of the two above Some applications might be linked directly to "-secure" or "-compat" to make sure they get one or the other. This is a bunch of work. At this time, with the resources at our disposal, I think it makes more sense to take a more gradual approach and just drop the assembly support. > Being the "swiss army knife" is no bad thing (even where that includes > old crypto). We just have to find a way to separate the two concerns: > current crypto (and only current crypto) for most (and probably most > importantly for libssl users); broader crypto support for those that > want it (which is why I like the liblegacycrypto idea because it enables > us to do that). I like the idea, but don't see a manageable implementation... > Whether this is the right thing to do in the 1.1.0 timeframe is another > consideration though. Viktor's arguments are quite convincing. The timeline is a concern. We're fairly far into the 1.1.0 development cycle (alphas and betas soon), and this is a major change. I think major changes like removing the ciphers or a whole new optional library should wait for a better opportunity. -- Viktor. From dnsands at sandia.gov Tue Nov 17 00:22:34 2015 From: dnsands at sandia.gov (Sands, Daniel) Date: Tue, 17 Nov 2015 00:22:34 +0000 Subject: [openssl-dev] [EXTERNAL] Re: Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151117000109.GS18315@mournblade.imrryr.org> References: <564A653E.8000000@openssl.org> <564A6588.9090908@openssl.org> <20151117000109.GS18315@mournblade.imrryr.org> Message-ID: <1447719753.2456.3.camel@sandia.gov> On Tue, 2015-11-17 at 00:01 +0000, Viktor Dukhovni wrote: On Mon, Nov 16, 2015 at 11:23:52PM +0000, Matt Caswell wrote: Disabling algorithms isn't the right answer IMO. I do like the idea of a "liblegacycrypto". That way people that only have need of current up-to-date crypto can stick with the main library. Others who need the older crypto can still get at it. Yes, that means we still have to maintain this code - but I don't see it as that big a burden. What becomes a bit tricky is having an EVP interface that can find the algorithms in liblegacrypto. This I think means two different builds of the crypto library, one that depends on liblegacycrypto and provides its algorithms, and another than does not. Is this beyond the necessity to register EVP algorithms? If not, a simple function call to register the legacy crypto functions, which would be contained in the legacy library, should be enough. Some applications might be linked directly to "-secure" or "-compat" to make sure they get one or the other. This is a bunch of work. If you're going to re-link at all, then the above suggestion seems like less cost. For the legacy library, it would simply be maintained as if it were a 3rd party add-on. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalten at au1.ibm.com Tue Nov 17 02:06:59 2015 From: pwalten at au1.ibm.com (Peter Waltenberg) Date: Tue, 17 Nov 2015 12:06:59 +1000 Subject: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151117000109.GS18315@mournblade.imrryr.org> References: <564A653E.8000000@openssl.org> <564A6588.9090908@openssl.org> <20151117000109.GS18315@mournblade.imrryr.org> Message-ID: <201511170209.tAH29GcD028824@d23av02.au.ibm.com> Why not offer another set of get_XYZ_byname() which resticts the caller to socially acceptable algorithms. Or allows the opposite, it really doesn't matter but restricted being the newer API breaks less code by default. Give it the same call syntax and it's simply an #ifdef in the OpenSSL headers for anyone who wants to spend hours working out why their code doesn't work any more. i.e. EVP_get_digestbyname() becomes EVP_get_digestbyname_r(), and if anyone actually wants only the restricted set from say a Linux distro. they can #define EVP_get_digestbyname(a) EVP_get_digestbyname_r(a) At the crypto library level this is just maths and it really doesn't make any sense to try and enforce policy at this point. I can understand the maintenance issues, but C code really isn't a problem and dropping algorithms from the sources here simply makes more work for other people elsewhere. Peter From: Viktor Dukhovni To: openssl-dev at openssl.org Date: 17/11/2015 10:02 Subject: Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback Sent by: "openssl-dev" On Mon, Nov 16, 2015 at 11:23:52PM +0000, Matt Caswell wrote: > Disabling algorithms isn't the right answer IMO. I do like the idea of a > "liblegacycrypto". That way people that only have need of current > up-to-date crypto can stick with the main library. Others who need the > older crypto can still get at it. Yes, that means we still have to > maintain this code - but I don't see it as that big a burden. What becomes a bit tricky is having an EVP interface that can find the algorithms in liblegacrypto. This I think means two different builds of the crypto library, one that depends on liblegacycrypto and provides its algorithms, and another than does not. Systems might then ship with: libcrypto-legacy.so - Just the legacy algorithms libcrypto-compat.so - Libcrypto that supports the above libcrypto-secure.so - Libcrypto with just the strong algos libcrypto.so - Symlink to one of the two above Some applications might be linked directly to "-secure" or "-compat" to make sure they get one or the other. This is a bunch of work. At this time, with the resources at our disposal, I think it makes more sense to take a more gradual approach and just drop the assembly support. > Being the "swiss army knife" is no bad thing (even where that includes > old crypto). We just have to find a way to separate the two concerns: > current crypto (and only current crypto) for most (and probably most > importantly for libssl users); broader crypto support for those that > want it (which is why I like the liblegacycrypto idea because it enables > us to do that). I like the idea, but don't see a manageable implementation... > Whether this is the right thing to do in the 1.1.0 timeframe is another > consideration though. Viktor's arguments are quite convincing. The timeline is a concern. We're fairly far into the 1.1.0 development cycle (alphas and betas soon), and this is a major change. I think major changes like removing the ciphers or a whole new optional library should wait for a better opportunity. -- Viktor. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From rsalz at akamai.com Tue Nov 17 02:13:54 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 17 Nov 2015 02:13:54 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> <16838026.jLb3FpZjMu@pintsize.usersys.redhat.com> Message-ID: <9851643599e344659ac6319399d73c7f@usma1ex-dag1mb1.msg.corp.akamai.com> ? If you are aware of a concrete use of MD2 or any of the other algorithms, please let us know! Also, note that we have an extended alpha and-beta test period, so we can add things back if mistakes are made. /r$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Nov 17 03:58:53 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 17 Nov 2015 03:58:53 +0000 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <16838026.jLb3FpZjMu@pintsize.usersys.redhat.com> <2923076.EjhxOnJbK2@pintsize.usersys.redhat.com> Message-ID: <30594cc55a024d9d9a8c90e727a10b69@usma1ex-dag1mb1.msg.corp.akamai.com> > Don?t punish users for choosing OpenSSL library to handle their non-SSL cryptographic needs and implicitly trusting the developers that they won?t be left in the cold. Can we please be less inflammatory? Old unused code is a security risk. We?re trying to reduce the attack surface *responsibly.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Nov 17 10:03:08 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 17 Nov 2015 10:03:08 +0000 Subject: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151117000109.GS18315@mournblade.imrryr.org> References: <564A653E.8000000@openssl.org> <564A6588.9090908@openssl.org> <20151117000109.GS18315@mournblade.imrryr.org> Message-ID: <564AFB5C.4050806@openssl.org> On 17/11/15 00:01, Viktor Dukhovni wrote: > On Mon, Nov 16, 2015 at 11:23:52PM +0000, Matt Caswell wrote: > >> Disabling algorithms isn't the right answer IMO. I do like the idea of a >> "liblegacycrypto". That way people that only have need of current >> up-to-date crypto can stick with the main library. Others who need the >> older crypto can still get at it. Yes, that means we still have to >> maintain this code - but I don't see it as that big a burden. > > What becomes a bit tricky is having an EVP interface that can find > the algorithms in liblegacrypto. This I think means two different > builds of the crypto library, one that depends on liblegacycrypto > and provides its algorithms, and another than does not. Is this just limited to OpenSSL_add_all_algorithms()/OpenSSL_add_all_ciphers()/OpenSSL_add_all_digests()? How about if those were macros that just picked up the relevant implementation based on a define. So in evp.h, something like: #ifdef OPENSSL_LEGACY_ALGS void OpenSSL_add_all_legacy_algorithms(); void OpenSSL_add_all_legacy_ciphers(); void OpenSSL_add_all_legacy_digests(); #define OpenSSL_add_all_algorithms() OpenSSL_add_all_legacy_algorithms() #define OpenSSL_add_all_ciphers() OpenSSL_add_all_legacy_ciphers() #define OpenSSL_add_all_digests() OpenSSL_add_all_legacy_digests() #else void OpenSSL_add_all_main_algorithms(); void OpenSSL_add_all_main_ciphers(); void OpenSSL_add_all_main_digests(); #define OpenSSL_add_all_algorithms() OpenSSL_add_all_main_algorithms() #define OpenSSL_add_all_ciphers() OpenSSL_add_all_main_ciphers() #define OpenSSL_add_all_digests() OpenSSL_add_all_main_digests() #endif OpenSSL_add_all_legacy_ciphers() would call OpenSSL_add_all_main_ciphers() and add all the legacy ones in too. Similarly for the other functions. Then you just compile apps which don't need legacy support with "-lcrypto", and apps that do with "-DOPENSSL_LEGACY_ALGS -lcrypto -lcrypto-legacy" > > Systems might then ship with: > > libcrypto-legacy.so - Just the legacy algorithms > > libcrypto-compat.so - Libcrypto that supports the above > libcrypto-secure.so - Libcrypto with just the strong algos > > libcrypto.so - Symlink to one of the two above > > Some applications might be linked directly to "-secure" or "-compat" > to make sure they get one or the other. This is a bunch of work. I don't think you would need libcrypto-compat if you took the approach above. I'm wondering whether splitting libcrypto into 3 might be worthwhile: libcrypto-core.so - Core elements of libcrypto needed by libssl libcrypto.so - Would depend on libcrypto-core. Adds mainstream and current crypto stuff that isn't needed by libssl libcrypto-legacy.so - Would depend on libcrypto and libcrypto-core. Just the legacy algorithms. That way users who only have an interest in libssl don't have to carry around all the other stuff that libcrypto provides - only those bits they need. Apps using libcrypto directly can mostly just forget about libcrypto-legacy and just add it if they really need it. Matt From noloader at gmail.com Tue Nov 17 10:12:11 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 17 Nov 2015 05:12:11 -0500 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> Message-ID: > MD2 - (The argument that someone somewhere may want to keep verifying old > MD2 signatures on self-signed certs doesn't seem like a compelling enough > reason to me. It's been disabled by default since OpenSSL 1.0.0.) > ... Apple still provides two Verisign certificates using md2WithRSAEncryption. Confer, https://support.apple.com/en-us/HT203065. Jeff From noloader at gmail.com Tue Nov 17 10:22:34 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 17 Nov 2015 05:22:34 -0500 Subject: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <201511170209.tAH29GcD028824@d23av02.au.ibm.com> References: <564A653E.8000000@openssl.org> <564A6588.9090908@openssl.org> <20151117000109.GS18315@mournblade.imrryr.org> <201511170209.tAH29GcD028824@d23av02.au.ibm.com> Message-ID: On Mon, Nov 16, 2015 at 9:06 PM, Peter Waltenberg wrote: > Why not offer another set of get_XYZ_byname() which resticts the caller to > socially acceptable algorithms. Or allows the opposite, it really doesn't > matter but restricted being the newer API breaks less code by default. > This is an interesting idea. For completeness, it has failed in other contexts. For example, the IETF's TLS Working Group refuses to provide such an abstraction. See, for example, https://www.ietf.org/mail-archive/web/tls/current/msg17611.html. -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilia at openssl.org Tue Nov 17 12:21:03 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Tue, 17 Nov 2015 13:21:03 +0100 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> Message-ID: On Tue, Nov 17, 2015 at 11:12 AM, Jeffrey Walton wrote: > > MD2 - (The argument that someone somewhere may want to keep verifying old > > MD2 signatures on self-signed certs doesn't seem like a compelling enough > > reason to me. It's been disabled by default since OpenSSL 1.0.0.) > > ... > Apple still provides two Verisign certificates using > md2WithRSAEncryption. Confer, > https://support.apple.com/en-us/HT203065. > Setting aside the debate of whether verifying trust store signatures is useful, whether verifying MD2 signatures has any practical security value, or whether OpenSSL + iOS is a meaningful combination: This is iOS7. The current release is iOS9 (trust store here: https://support.apple.com/en-us/HT205205, MD2 certs are gone). Arguments like this illustrate a fundamental misunderstanding in this thread. We are not pulling the carpet from any users TODAY. We are asking whether there are applications that will need this code 2..3..5 years down the line. When I referred to the fact that users of 1.1 will have to recompile, I didn't mean that errors would be revealed by recompilation. I meant that you would have to be an actively maintained application or library, and be doing a new release, and be stuck using an old algorithm, to even be impacted by this change. > Jeff > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Nov 17 17:43:44 2015 From: rt at openssl.org (Jun Sun via RT) Date: Tue, 17 Nov 2015 17:43:44 +0000 Subject: [openssl-dev] [openssl.org #4142] Fail to detect Xcode 7 for Intel AVX code In-Reply-To: References: Message-ID: Hi, I just found the perl script for x86_64 assembly failed to detect Xcode 7 environment (Apple LLVM 7.x), and skipped generating AVX code for MAC OS ($avx variable is always false). The reason is Apple since Xcode 7.0 removed string "based on LLVM x.y.z" from version information. Now the clang -v command returns: Apple LLVM version 7.0.0 (clang-700.1.76) Target: x86_64-apple-darwin15.0.0 Thread model: posix So the way to detect compiler version becomes to check either "LLVM version" or "clang-". Here is a patch to check the first string (take rsaz-avx2.pl as an example): if (!$avx && `$ENV{CC} -v 2>&1` =~ /LLVM version ([0-9]+)\./) { $avx = ($1>=5) + ($1>=5); $addx = ($1>=5); } Version number 5 is used but not 7 due to the reason Apple start AVX support from Xcode 5 (LLVM 5). A list of Xcode records can be found here: https://gist.github.com/yamaya/2924292 [https://avatars0.githubusercontent.com/u/278790?v=3&s=400] Xcode clang version record ? GitHub After today's update of command line tools/xcode I get: About Xcode: Version 6.3 (6D570) /usr/bin/clang++ --version Apple LLVM version 6.1.0 (clang-602.0.49) (based ... Read more... This email and any attachments are for the sole use of the intended recipients and may be privileged or confidential. Any distribution, printing or other use by anyone else is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and attachments. -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Tue Nov 17 17:43:44 2015 From: rt at openssl.org (Geoff Beier via RT) Date: Tue, 17 Nov 2015 17:43:44 +0000 Subject: [openssl-dev] [openssl.org #4143] bug: fips_premain_dso.exe does not include applink.c on dll fips builds In-Reply-To: References: Message-ID: When rebuilding with VS 2015 tools, the build fails when fips_premain_dso is executed because it does not include applink.c. The attached patch to mk1mf.pl fixes the makefile generation. Because static builds still build fips_premain_dso.exe but do not need applink.c, shared builds are special-cased in the patch. Thanks, Geoff -------------- next part -------------- A non-text attachment was scrubbed... Name: mk1mf.patch Type: application/octet-stream Size: 815 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Tue Nov 17 17:43:45 2015 From: rt at openssl.org (Richard PALO via RT) Date: Tue, 17 Nov 2015 17:43:45 +0000 Subject: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options In-Reply-To: <564B39A2.9040807@netbsd.org> References: <564B39A2.9040807@netbsd.org> Message-ID: I'd like to propose the attached patch to 1.0.2d which avoids problems with strict ISO conforming compiler/options, which do not define 'sun' only '__sun' as usual... such as gcc/clang -std=c99 This affects the build itself, but also any user of openssl/opensslconf.h -- Richard PALO -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-__sun-instead-of-sun-for-strict-ISO-conforming-c.patch Type: text/x-patch Size: 6464 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Tue Nov 17 17:58:02 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Tue, 17 Nov 2015 17:58:02 +0000 Subject: [openssl-dev] [openssl.org #4124] Illegal instruction when using aes-ni-sha256 stitched implementation on AMD CPU In-Reply-To: <20151117175752.GA25174@roeckx.be> References: <1446731461.2626.27.camel@redhat.com> <20151117175752.GA25174@roeckx.be> Message-ID: On Sun, Nov 08, 2015 at 11:37:55AM +0000, Tomas Mraz via RT wrote: > The aes-ni-sha256 stitched implementation causes SIGILL on AMD A4-6210. > It is caused by not using the AVX+SSSE3 code path for non-Intel CPUs > although the CPU seems to be fully capable of running it. The issue is now fixed in git. Kurt From noloader at gmail.com Tue Nov 17 18:00:44 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 17 Nov 2015 13:00:44 -0500 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> Message-ID: On Tue, Nov 17, 2015 at 7:21 AM, Emilia K?sper wrote: > > > On Tue, Nov 17, 2015 at 11:12 AM, Jeffrey Walton wrote: >> >> > MD2 - (The argument that someone somewhere may want to keep verifying >> > old >> > MD2 signatures on self-signed certs doesn't seem like a compelling >> > enough >> > reason to me. It's been disabled by default since OpenSSL 1.0.0.) >> > ... >> Apple still provides two Verisign certificates using >> md2WithRSAEncryption. Confer, >> https://support.apple.com/en-us/HT203065. > > > Setting aside the debate of whether verifying trust store signatures is > useful, whether verifying MD2 signatures has any practical security value, > or whether OpenSSL + iOS is a meaningful combination: > > This is iOS7. The current release is iOS9 (trust store here: > https://support.apple.com/en-us/HT205205, MD2 certs are gone). > > Arguments like this illustrate a fundamental misunderstanding in this > thread. We are not pulling the carpet from any users TODAY. We are asking > whether there are applications that will need this code 2..3..5 years down > the line. My bad... I was not arguing either way. I was just presenting facts. Also, if OpenSSL requires iOS 9 or above, then its setting policy for users. I still have iOS 6, 7 and 8 devices because (1) some of my hardware is old and abandoned by Apple (they are trying to set policy, too, in an effort to boost sales). (2) I dislike the "cartoony" interface of iOS 7 and above. (3) I have down level OS X operating systems (due to operational requirements and personal taste), and they can't talk to iOS 8 or 9 devices. Jeff From rt at openssl.org Tue Nov 17 18:09:56 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Tue, 17 Nov 2015 18:09:56 +0000 Subject: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options In-Reply-To: <20151117180953.GA25285@roeckx.be> References: <564B39A2.9040807@netbsd.org> <20151117180953.GA25285@roeckx.be> Message-ID: On Tue, Nov 17, 2015 at 05:43:45PM +0000, Richard PALO via RT wrote: > I'd like to propose the attached patch to 1.0.2d which avoids problems > with strict ISO conforming compiler/options, which do not define 'sun' only > '__sun' as usual... such as gcc/clang -std=c99 I fail to understand how this would cause any problems for you. Also, we're not targetting C99, we're still at C89/C90 with some extentions. If a newer standard conflicts we should of course try to fix it, but it build just as fine using gnu99 or gnu11 for me. Kurt From rt at openssl.org Tue Nov 17 18:33:22 2015 From: rt at openssl.org (Richard PALO via RT) Date: Tue, 17 Nov 2015 18:33:22 +0000 Subject: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options In-Reply-To: <564B72EB.2050706@netbsd.org> References: <564B39A2.9040807@netbsd.org> <20151117180953.GA25285@roeckx.be> <564B72EB.2050706@netbsd.org> Message-ID: Le 17/11/15 19:09, Kurt Roeckx via RT a ?crit : > On Tue, Nov 17, 2015 at 05:43:45PM +0000, Richard PALO via RT wrote: >> I'd like to propose the attached patch to 1.0.2d which avoids problems >> with strict ISO conforming compiler/options, which do not define 'sun' only >> '__sun' as usual... such as gcc/clang -std=c99 > > I fail to understand how this would cause any problems for you. > Also, we're not targetting C99, we're still at C89/C90 with some > extentions. If a newer standard conflicts we should of course try > to fix it, but it build just as fine using gnu99 or gnu11 for me. > > > Kurt Straight from Oracle concerning Solaris: > > #ifdef __sun > Sun compiler > #endif > #ifdef __SUNPRO_C > Sun C compiler /* __SUNPRO_C value is the version number */ > #endif > #ifdef __SUNPRO_CC > Sun C++ compiler /* __SUNPRO_CC value is the version number */ > #endif > #ifdef __sparc > generate code for SPARC (R) architecture > #endif > #ifdef __sparcv9 > generate code for 64-bit SPARC architecture > #endif > #ifdef __i386 > generate code for x86 architecture > #endif > #ifdef __amd64 > generate code for x64 architecture > #endif > Using 'sun' is an extension and has not been recommended for years (decades?) Strict ISO conforming compilers don't define 'sun', only __sun. examples: cc -Xc -xc99; gcc -std=c99; clang -std=c99 As I mentioned, there are two issues: 1. building openssl with a strict ISO conforming compiler 2. building other programs including opensslconf.h with a strict ISO compiler cheers -- Richard PALO From fw at deneb.enyo.de Tue Nov 17 18:10:00 2015 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 17 Nov 2015 19:10:00 +0100 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151114173215.GX18315@mournblade.imrryr.org> (Viktor Dukhovni's message of "Sat, 14 Nov 2015 17:32:16 +0000") References: <1447434484727.167123.bfa0e6052041fbef094cd397c7d2af1a0f777f4c@spica.telekom.de> <564625F5.1050703@eCosCentric.com> <20151113194841.GP18315@mournblade.imrryr.org> <876115lkgl.fsf@alice.fifthhorseman.net> <20151113211656.GQ18315@mournblade.imrryr.org> <140967ab0756449ab177bcf74684a97d@usma1ex-dag1mb1.msg.corp.akamai.com> <20151113215624.GR18315@mournblade.imrryr.org> <7e49287e4f6b4406a2f8d93fd38fe914@usma1ex-dag1mb1.msg.corp.akamai.com> <201511140733.tAE7XdL3004819@d23av05.au.ibm.com> <20151114173215.GX18315@mournblade.imrryr.org> Message-ID: <87y4dwebuv.fsf@mid.deneb.enyo.de> * Viktor Dukhovni: > If I were to guess, it would be that the base crypto implementations > of IDEA, SEED and binary elliptic curves need to stay. We could > perhaps get away with removing CAST and RIPEMD. Just one data point: CAST5 is still the default for GnuPG when using symmetric encryption. Florian From rt at openssl.org Tue Nov 17 18:47:55 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Tue, 17 Nov 2015 18:47:55 +0000 Subject: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options In-Reply-To: <20151117184750.GA9164@roeckx.be> References: <564B39A2.9040807@netbsd.org> <20151117180953.GA25285@roeckx.be> <564B72EB.2050706@netbsd.org> <20151117184750.GA9164@roeckx.be> Message-ID: On Tue, Nov 17, 2015 at 06:33:22PM +0000, Richard PALO via RT wrote: > > Strict ISO conforming compilers don't define 'sun', only __sun. Ah, I clearly misunderstood your earlier message. Kurt From kurt at roeckx.be Tue Nov 17 18:48:34 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 17 Nov 2015 19:48:34 +0100 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <87y4dwebuv.fsf@mid.deneb.enyo.de> References: <564625F5.1050703@eCosCentric.com> <20151113194841.GP18315@mournblade.imrryr.org> <876115lkgl.fsf@alice.fifthhorseman.net> <20151113211656.GQ18315@mournblade.imrryr.org> <140967ab0756449ab177bcf74684a97d@usma1ex-dag1mb1.msg.corp.akamai.com> <20151113215624.GR18315@mournblade.imrryr.org> <7e49287e4f6b4406a2f8d93fd38fe914@usma1ex-dag1mb1.msg.corp.akamai.com> <201511140733.tAE7XdL3004819@d23av05.au.ibm.com> <20151114173215.GX18315@mournblade.imrryr.org> <87y4dwebuv.fsf@mid.deneb.enyo.de> Message-ID: <20151117184833.GB9164@roeckx.be> On Tue, Nov 17, 2015 at 07:10:00PM +0100, Florian Weimer wrote: > * Viktor Dukhovni: > > > If I were to guess, it would be that the base crypto implementations > > of IDEA, SEED and binary elliptic curves need to stay. We could > > perhaps get away with removing CAST and RIPEMD. > > Just one data point: CAST5 is still the default for GnuPG when using > symmetric encryption. Not in gnupg 2 afaik. Kurt From noloader at gmail.com Tue Nov 17 19:01:11 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 17 Nov 2015 14:01:11 -0500 Subject: [openssl-dev] [openssl.org #4142] Fail to detect Xcode 7 for Intel AVX code In-Reply-To: References: Message-ID: On Tue, Nov 17, 2015 at 12:43 PM, Jun Sun via RT wrote: > Hi, > > I just found the perl script for x86_64 assembly failed to detect Xcode 7 environment (Apple LLVM 7.x), and skipped generating AVX code for MAC OS ($avx variable is always false). The reason is Apple since Xcode 7.0 removed string "based on LLVM x.y.z" from version information. Now the clang -v command returns: > > > Apple LLVM version 7.0.0 (clang-700.1.76) > > Target: x86_64-apple-darwin15.0.0 > > Thread model: posix > > So the way to detect compiler version becomes to check either "LLVM version" or "clang-". Here is a patch to check the first string (take rsaz-avx2.pl as an example): Apple has changed these strings a few times over the years. I'm just bike shedding, but I think the way to proceed s to (1) detect the Clang version (similar to what you propose), and then (2) look for __APPLE_CC__ in the preprocessor. If (1) and (2) are met, then you have an Apple port. Also be awya that folks like MacPorts and Fink provide Clang compilers for OS X, too. They *lack* __APPLE_CC__ in the preprocessor. For example: $ c++ -x c++ -dM -E - References: Message-ID: On Tue, Nov 17, 2015 at 12:43 PM, Jun Sun via RT wrote: > Hi, > > I just found the perl script for x86_64 assembly failed to detect Xcode 7 environment (Apple LLVM 7.x), and skipped generating AVX code for MAC OS ($avx variable is always false). The reason is Apple since Xcode 7.0 removed string "based on LLVM x.y.z" from version information. Now the clang -v command returns: > > > Apple LLVM version 7.0.0 (clang-700.1.76) > > Target: x86_64-apple-darwin15.0.0 > > Thread model: posix > > So the way to detect compiler version becomes to check either "LLVM version" or "clang-". Here is a patch to check the first string (take rsaz-avx2.pl as an example): Apple has changed these strings a few times over the years. I'm just bike shedding, but I think the way to proceed s to (1) detect the Clang version (similar to what you propose), and then (2) look for __APPLE_CC__ in the preprocessor. If (1) and (2) are met, then you have an Apple port. Also be awya that folks like MacPorts and Fink provide Clang compilers for OS X, too. They *lack* __APPLE_CC__ in the preprocessor. For example: $ c++ -x c++ -dM -E - References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> Message-ID: <564B7D9E.2030009@akamai.com> On 11/17/2015 12:00 PM, Jeffrey Walton wrote: > > > Also, if OpenSSL requires iOS 9 or above, then its setting policy for users. In some sense, yes. But it has always done so -- OpenSSL only supports certain platforms, and certain versions of certain platforms. There are prerequisites to being able to build any piece of software, and those prerequisites can and must change as new versions of that software are released. In particular... > I still have iOS 6, 7 and 8 devices because (1) some of my hardware is > old and abandoned by Apple (they are trying to set policy, too, in an > effort to boost sales). (2) I dislike the "cartoony" interface of iOS > 7 and above. (3) I have down level OS X operating systems (due to > operational requirements and personal taste), and they can't talk to > iOS 8 or 9 devices. > Will Apple still be supporting even iOS 8 in two years? I find it hard to make a case that OpenSSL should make an active push to support platforms no longer receiving security updates, given that we are supposed to be security software. In your personal case, you seem happy to use older versions of OS X and iOS; what is different about those compared to OpenSSL that you could not continue using an older version of OpenSSL if you found some functionality of the old version to be preferable? -Ben From pwalten at au1.ibm.com Tue Nov 17 22:11:40 2015 From: pwalten at au1.ibm.com (Peter Waltenberg) Date: Wed, 18 Nov 2015 08:11:40 +1000 Subject: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <564A653E.8000000@openssl.org> <564A6588.9090908@openssl.org> <20151117000109.GS18315@mournblade.imrryr.org> <201511170209.tAH29GcD028824@d23av02.au.ibm.com> Message-ID: <201511172214.tAHME08n000355@d23av03.au.ibm.com> > This is an interesting idea. For completeness, it has failed in other contexts Well yes but it's a different context. Policy level rather than capability, That's why I'm not in favour of removing algorithms, even changing policy higher up the stack can cause problems, but removing basic capabilities tends to have even unwanted side effects. I obviously have a personal interest in this, in my case it's because I work for a company that does provide insane support lifetimes for products. For libcrypto itself the attack surface is near zero, it doesn't open sockets, connect to networks, accept input. It's simply a toolbox and there's always something else between libcrypto and an attack, if SSL doesn't want to use MD5, well don't use MD5 but there are other users of the toolbox. As an analogy throwing out all those 3/8th spanners just because you've officially gone metric doesn't always work that well in practice either. Peter Phone: 61-7-5552-4016 L11 & L7 Seabank E-mail: pwalten at au1.ibm.com Southport, QLD 4215 Australia From: Jeffrey Walton To: OpenSSL Developer ML Date: 17/11/2015 20:23 Subject: Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback Sent by: "openssl-dev" On Mon, Nov 16, 2015 at 9:06 PM, Peter Waltenberg wrote: Why not offer another set of get_XYZ_byname() which resticts the caller to socially acceptable algorithms. Or allows the opposite, it really doesn't matter but restricted being the newer API breaks less code by default. This is an interesting idea. For completeness, it has failed in other contexts. For example, the IETF's TLS Working Group refuses to provide such an abstraction. See, for example, https://www.ietf.org/mail-archive/web/tls/current/msg17611.html. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From fw at deneb.enyo.de Tue Nov 17 22:29:56 2015 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 17 Nov 2015 23:29:56 +0100 Subject: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151117184833.GB9164@roeckx.be> (Kurt Roeckx's message of "Tue, 17 Nov 2015 19:48:34 +0100") References: <564625F5.1050703@eCosCentric.com> <20151113194841.GP18315@mournblade.imrryr.org> <876115lkgl.fsf@alice.fifthhorseman.net> <20151113211656.GQ18315@mournblade.imrryr.org> <140967ab0756449ab177bcf74684a97d@usma1ex-dag1mb1.msg.corp.akamai.com> <20151113215624.GR18315@mournblade.imrryr.org> <7e49287e4f6b4406a2f8d93fd38fe914@usma1ex-dag1mb1.msg.corp.akamai.com> <201511140733.tAE7XdL3004819@d23av05.au.ibm.com> <20151114173215.GX18315@mournblade.imrryr.org> <87y4dwebuv.fsf@mid.deneb.enyo.de> <20151117184833.GB9164@roeckx.be> Message-ID: <87io50dztn.fsf@mid.deneb.enyo.de> * Kurt Roeckx: > On Tue, Nov 17, 2015 at 07:10:00PM +0100, Florian Weimer wrote: >> * Viktor Dukhovni: >> >> > If I were to guess, it would be that the base crypto implementations >> > of IDEA, SEED and binary elliptic curves need to stay. We could >> > perhaps get away with removing CAST and RIPEMD. >> >> Just one data point: CAST5 is still the default for GnuPG when using >> symmetric encryption. > > Not in gnupg 2 afaik. Debian stable has GnuPG 2.0.26, and it still uses CAST5: $ gpg2 --batch --passphrase - -c < /dev/null | gpg2 --batch --passphrase - --list-packets :symkey enc packet: version 4, cipher 3, s2k 3, hash 2 salt 45c1df2dc3dd11c2, count 2490368 (179) gpg: CAST5 encrypted data :encrypted data packet: length: 22 gpg: encrypted with 1 passphrase :compressed packet: algo=1 :literal data packet: mode b (62), created 1447798993, name="", raw data: 0 bytes gpg: WARNING: message was not integrity protected GnuPG 2.0 is still ?the stable version suggested for most users?, unfortunately. GnuPG 2.1 has indeed switched to AES-128, but only in September 2014. Florian From rt at openssl.org Tue Nov 17 23:26:21 2015 From: rt at openssl.org (Yusheng Yang via RT) Date: Tue, 17 Nov 2015 23:26:21 +0000 Subject: [openssl-dev] [openssl.org #4146] Bug: expired CRL makes X509_verify_cert crash if X509_STORE_CTX is initialized without an X509_STORE In-Reply-To: References: Message-ID: Scenario: RedHat Linux 2.6.32-131.0.15.el6.x86_64 OpenSSL 1.0.1L openssl.cnf: crlnumber = crlnumber default_crl_days = 30 generate CRL: echo 01 > crlnumber openssl ca -config openssl.cnf -batch -revoke peerRevoked.pem openssl ca -config openssl.cnf -batch -gencrl -out cacrl.crl Let 30 days pass. X509* x = *PEM_read_bio_X509_AUX*(memoryBioCorrespondingToPeerRevoked.pem, NULL, NULL, NULL); *STACK_OF*(X509) *tchain = result_of_load_certs_from_apps.c(cacert.pem); *STACK_OF*(X509_CRL) *crls = result_of_load_crls_from_apps.c(cacrl.crl); X509_STORE_CTX *csc = *X509_STORE_CTX_new*(); *X509_STORE_CTX_init*(csc, NULL, x, NULL); /* Problem doesn?t happen if second argument is non-NULL, as it is in apps/verify.c. */ *X509_STORE_CTX_trusted_stack*(csc, tchain); *X509_STORE_CTX_set0_crls*(csc, crls); X509_VERIFY_PARAM *vpm = *X509_STORE_CTX_get0_param*(csc); unsigned long flags = *X509_VERIFY_PARAM_get_flags*(vpm); flags |= X509_V_FLAG_CRL_CHECK; *X509_VERIFY_PARAM_set_flags*(vpm, flags); *X509_verify_cert*(csc); X509_verify_cert crashes with this stack trace: Program received signal SIGSEGV, Segmentation fault. 0x0000000000fac5ed in X509_STORE_get1_crls (ctx=0x1700c40, nm=0x16fe5f0) at x509_lu.c:546 546 idx = x509_object_idx_cnt(ctx->ctx->objs, X509_LU_CRL, nm, &cnt); Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.25.el6.x86_64 (gdb) display ctx->ctx 1: ctx->ctx = (X509_STORE *) 0x0 (gdb) bt #0 0x0000000000fac5ed in X509_STORE_get1_crls (ctx=0x1700c40, nm=0x16fe5f0) at x509_lu.c:546 #1 0x0000000000fa8cab in get_crl_delta (ctx=0x1700c40, pcrl=0x7fffffff6dd0, pdcrl=0x7fffffff6dc8, x=0x1700190) at x509_vfy.c:1322 #2 0x0000000000fa79d4 in check_cert (ctx=0x1700c40) at x509_vfy.c:711 #3 0x0000000000fa78d8 in check_revocation (ctx=0x1700c40) at x509_vfy.c:686 #4 0x0000000000fa6f45 in X509_verify_cert (ctx=0x1700c40) at x509_vfy.c:362 The problem is that ctx->ctx is NULL, and it?s dereferencing a NULL pointer. Perhaps x509_vfy.c get_crl_delta should only call ctx->lookup_crls if ctx->ctx is non-NULL. When running openssl verify on the same files, I see that ctx->lookup_crls returns no skcrl, so having NULL ctx->ctx should yield the same result. -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Tue Nov 17 23:26:21 2015 From: rt at openssl.org (William A. Rowe Jr. via RT) Date: Tue, 17 Nov 2015 23:26:21 +0000 Subject: [openssl-dev] [openssl.org #4145] Enhancement: patch to support s_client -starttls http In-Reply-To: References: Message-ID: RFC 2817 defines upgrading HTTP/1.1 to TLS (or SSL). Because Apache httpd supports Connection: Upgrade and Upgrade: TLS/1.x I've gone ahead and instrumented s_client to support this behavior (and noted a small optimization in the same logic stream for starttls support). Attached is the patch to introduce this behavior. It is a bit crufty, but lacking a CUPS client that did connection upgrade to TLS, I needed something for testing and experimentation. I don't know that there is a justification for implementing Upgrade: h2 since this is a binary protocol that is not conducive to terminal mode :) Source licensed by me under the OpenSSL license at https://www.openssl.org/source/license.txt - don't see a need for a CLA, but email me privately if so. -------------- next part -------------- A non-text attachment was scrubbed... Name: starttls-http.patch Type: text/x-patch Size: 3664 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Nov 18 03:52:54 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Wed, 18 Nov 2015 03:52:54 +0000 Subject: [openssl-dev] [openssl.org #4143] bug: fips_premain_dso.exe does not include applink.c on dll fips builds In-Reply-To: References: Message-ID: On Tue Nov 17 17:43:44 2015, geoff at redhoundsoftware.com wrote: > When rebuilding with VS 2015 tools, the build fails when fips_premain_dso > is executed because it does not include applink.c. The attached patch to > mk1mf.pl fixes the makefile generation. > > Because static builds still build fips_premain_dso.exe but do not need > applink.c, shared builds are special-cased in the patch. > Have you tried a recent snapshot of OpenSSL 1.0.1 or 1.0.2? This should already be fixed but hasn't appeared in an official release yet. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From cpservicespb at gmail.com Wed Nov 18 11:36:06 2015 From: cpservicespb at gmail.com (CpServiceSPb .) Date: Wed, 18 Nov 2015 14:36:06 +0300 Subject: [openssl-dev] OpenSSL as OCSP server (responder) as multithreading daemon ! Message-ID: Is it possible to include at nearest developing plans ability of running OpenSSL at Ocsp responder mode as multithreading daemon (Linux) and service (Windows) ? That is to add -daemon switch in conjunction with ocsp and -index (which causes OSSL acting as responder) . And in such way OSSL will serve many incoming OCSP requests in background mode got at listening port in additional current OCSP functional. To improve usability at such ocps reponder daemon mode txt DB file shoud be used; Format of the DB have to be look like index.txt and as followng: Status Serial Root Cert rkey parameter rcert parameter V 1021 /path/Root.pem /path/ocspserver.pem /path/ocspserver.pem V 3565 /path/Root.pem /path/ocspserver2.pem /path/ocspserver2.pem So, second parameter is serial number of certificate in OCSP request, Root cert equals -CAfile parameter of openssl ocsp -CAfile, rkey parameter & rcert parameter are respectivelly -rkey and rcert parameters. As follows, multiple certificate "checking" rules can be at Db. And when OSSL starts it loads this DB to a memory, parses requests (as now) and uses CAfile, rkey and rcert from DB for certificate with appropriate serial. Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Nov 18 11:44:52 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 18 Nov 2015 11:44:52 +0000 Subject: [openssl-dev] OpenSSL as OCSP server (responder) as multithreading daemon ! In-Reply-To: References: Message-ID: <6dff57c71d26461ab84121aab9932d81@usma1ex-dag1mb1.msg.corp.akamai.com> ? Is it possible to include at nearest developing plans ability of running OpenSSL at Ocsp responder mode as multithreading daemon (Linux) and service (Windows) ? We have no plans to do this. It would be nice to see something like this as a new open-source project. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Nov 18 12:46:05 2015 From: rt at openssl.org (Richard PALO via RT) Date: Wed, 18 Nov 2015 12:46:05 +0000 Subject: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options In-Reply-To: <564C72FF.10405@netbsd.org> References: <564B39A2.9040807@netbsd.org> <20151117180953.GA25285@roeckx.be> <564B72EB.2050706@netbsd.org> <20151117184750.GA9164@roeckx.be> <564C72FF.10405@netbsd.org> Message-ID: Le 17/11/15 19:47, Kurt Roeckx via RT a ?crit : > On Tue, Nov 17, 2015 at 06:33:22PM +0000, Richard PALO via RT wrote: >> >> Strict ISO conforming compilers don't define 'sun', only __sun. > > Ah, I clearly misunderstood your earlier message. > > > Kurt > Sorry, perhaps it was a bit terse... Here's a comparison of 'with extensions' and then 'strict' for studio > richard at omnis:/home/richard$ /opt/solarisstudio12.4/bin/cc -xc99 -E -xdumpmacros /dev/null |& egrep 'sun|svr4|SVR4' > #define __SVR4 1 > #define __sun 1 > #define sun 1 > richard at omnis:/home/richard$ /opt/solarisstudio12.4/bin/cc -Xc -xc99 -E -xdumpmacros /dev/null |& egrep 'sun|svr4|SVR4' > #define __SVR4 1 > #define __sun 1 and for gcc (or clang) > richard at omnis:/home/richard$ /opt/gcc-4.8.1/bin/gcc -std=gnu99 -E -dM - #define __SVR4 1 > #define __sun 1 > #define sun 1 > #define __sun__ 1 > #define __svr4__ 1 > richard at omnis:/home/richard$ /opt/gcc-4.8.1/bin/gcc -std=c99 -E -dM - #define __SVR4 1 > #define __sun 1 > #define __sun__ 1 > #define __svr4__ 1 -- Richard PALO From hkario at redhat.com Wed Nov 18 13:05:07 2015 From: hkario at redhat.com (Hubert Kario) Date: Wed, 18 Nov 2015 14:05:07 +0100 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: Message-ID: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> On Tuesday 17 November 2015 13:21:03 Emilia K?sper wrote: > On Tue, Nov 17, 2015 at 11:12 AM, Jeffrey Walton wrote: > > > MD2 - (The argument that someone somewhere may want to keep > > > verifying old MD2 signatures on self-signed certs doesn't seem > > > like a compelling enough reason to me. It's been disabled by > > > default since OpenSSL 1.0.0.) ... > > > > Apple still provides two Verisign certificates using > > md2WithRSAEncryption. Confer, > > https://support.apple.com/en-us/HT203065. > > Setting aside the debate of whether verifying trust store signatures > is useful, whether verifying MD2 signatures has any practical > security value, or whether OpenSSL + iOS is a meaningful combination: > > This is iOS7. The current release is iOS9 (trust store here: > https://support.apple.com/en-us/HT205205, MD2 certs are gone). > > Arguments like this illustrate a fundamental misunderstanding in this > thread. That's correct. But it exists on both sides of the argument. > We are not pulling the carpet from any users TODAY. We are > asking whether there are applications that will need this code > 2..3..5 years down the line. And I said that this code will certainly need to stay for 15 more, at the very least (more on that below). > When I referred to the fact that users > of 1.1 will have to recompile, I didn't mean that errors would be > revealed by recompilation. I meant that you would have to be an > actively maintained application or library, and be doing a new > release, and be stuck using an old algorithm, to even be impacted by > this change. Now, please, tell me: how often do you go though your e-mail archive and verify that you can decrypt and verify signatures on all the old email you have there? On Monday 16 November 2015 20:28:01 Richard Moore wrote: > On 16 November 2015 at 19:05, Hubert Kario wrote: > > Example: CAdES V1.2.2 was published in late 2000, the first serious > > attacks on MD2 were not published until 2004. I think it is not > > unreasonable for CAdES-A documents to exist today which were > > originally signed with MD2 while it was still considered secure and > > that are still relevant today, just 15 years later. > > ?This doesn't explain why the code needs to exist in future versions > of openssl. The previous ones aren't going to vanish and can be > compiled and used to rescue data in theoretical edge cases like this. It's not theoretical, I know that archival systems which use CAdES, PAdES or XAdES exist for over a decade now. > You're making it sound like this is making the data totally > inaccessible which is not the case. It *is* the case. There seems to be a lot of misunderstanding what I'm talking about so let me start from the beginning. As we all know, by having a RSA, DSA or ECDSA key pair (among others), it is possible to create digital signatures of electronic documents. Files really. It proves that a given document was created (or at least viewed) by a user which signed the document. But the key sizes appropriate for proving that the signature was not constructed (counterfeited) changes in time. Same with key sizes supported by typical PKCS#11 tokens - 10 years ago a typical USB token wouldn't be able to create a 2048 bit RSA signature. As we're discussing here, the hash algorithms considered as secure also change, with some being broken as time goes one and new being created. Finally, the key used for signing may be compromised or lost. And even if not, it will loose validity at the "notAfter" date. The CA will loose validity too, worse, it may stop existing completely... This creates a problem - how do I prove that a given document was signed while the key size was still appropriate, the hash algorithm was still considered secure and the certificates were still valid and not-revoked? The answer is: use a trusted third party that will sign a hash provided by you together with a date provided by itself. It's a notary service, proving existence of some data at some point in time. It creates a Time Stamp. Now on the scene enter Qualified Digital Signatures. In other words, signatures which are considered to be equivalent to paper signatures in _everything_ for all purposes under the law - marriage certificates, business agreements, medical records, tax reports, etc. They require registration (in person) with a state certified CA and use of essentially a FIPS 140-3 Level 3 HSM for generating and storing the key. This extends the problem of Time Stamps. Since many legal documents MUST be kept for decades (30 years is not uncommon) we need to deal with not only compromises of private keys, key sizes or hashes getting obsoleted but _entire cryptosystems_ becoming obsolete. The solution to this problem, is to regularly time stamp the document together with all data necessary to verify original signature and all subsequent timestamps (that means, CA certificates, intermediate CA certificates, end-user certificates, OCSP responses, CRLs and time stamps). This way, it is possible to digitally certify that any cryptosystems, signatures and timestamps were created before they could have been broken. Now, to verify that all the data necessary for verification of previous signatures (be it on certificates, time stamps or the original document) is correct, the application MUST verify all those signatures (legal requirement) *before* it adds a new timestamp. And since those time stamps need to be created using Qualified certificates too, usually access to those Time Stamping Authorities is limited by TLS with user certificates, so that users need to buy every timestamp. So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to support both relatively modern TLS with user certificates, preferably the newest cryptosystems and hashes as well as the oldest ones that were standardised and used. That means that old algorithms MUST remain in OpenSSL as supported functionality. It may require linking to a specific library to make the EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed from it completely, definitely not before at least 50 years _after_ they became obsolete and broken. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From hkario at redhat.com Wed Nov 18 13:39:15 2015 From: hkario at redhat.com (Hubert Kario) Date: Wed, 18 Nov 2015 14:39:15 +0100 Subject: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151117000109.GS18315@mournblade.imrryr.org> References: <564A653E.8000000@openssl.org> <564A6588.9090908@openssl.org> <20151117000109.GS18315@mournblade.imrryr.org> Message-ID: <7467784.FaYEkqzf4f@pintsize.usersys.redhat.com> On Tuesday 17 November 2015 00:01:09 Viktor Dukhovni wrote: > On Mon, Nov 16, 2015 at 11:23:52PM +0000, Matt Caswell wrote: > > Disabling algorithms isn't the right answer IMO. I do like the idea > > of a "liblegacycrypto". That way people that only have need of > > current up-to-date crypto can stick with the main library. Others > > who need the older crypto can still get at it. Yes, that means we > > still have to maintain this code - but I don't see it as that big a > > burden. > What becomes a bit tricky is having an EVP interface that can find > the algorithms in liblegacrypto. This I think means two different > builds of the crypto library, one that depends on liblegacycrypto > and provides its algorithms, and another than does not. > > Systems might then ship with: > > libcrypto-legacy.so - Just the legacy algorithms > > libcrypto-compat.so - Libcrypto that supports the above > libcrypto-secure.so - Libcrypto with just the strong algos > > libcrypto.so - Symlink to one of the two above > > Some applications might be linked directly to "-secure" or "-compat" > to make sure they get one or the other. This is a bunch of work. > > At this time, with the resources at our disposal, I think it makes > more sense to take a more gradual approach and just drop the assembly > support. how about having a runtime registry of supported algorithms, and having the libcrypto-legacy.so simply add algorithms to this list at load? or is this mechanism not supported by some environments supported by openssl? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From wrowe at rowe-clan.net Wed Nov 18 14:25:04 2015 From: wrowe at rowe-clan.net (William A Rowe Jr) Date: Wed, 18 Nov 2015 08:25:04 -0600 Subject: [openssl-dev] [openssl.org #4145] Enhancement: patch to support s_client -starttls http In-Reply-To: References: Message-ID: Please note my typo identified by a dev at httpd, Yann... A little note, probably some missing == here: + else if (meth = TLSv1_2_client_method()) + BIO_printf(fbio, "Upgrade: TLS/1.2\r\n"); + else if (meth = TLSv1_1_client_method()) + BIO_printf(fbio, "Upgrade: TLS/1.1\r\n"); + else if (meth = TLSv1_client_method()) + BIO_printf(fbio, "Upgrade: TLS/1.0\r\n"); Revised patch attached. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: starttls-http-v2.patch Type: text/x-patch Size: 3677 bytes Desc: not available URL: From rt at openssl.org Wed Nov 18 14:25:16 2015 From: rt at openssl.org (William A. Rowe Jr. via RT) Date: Wed, 18 Nov 2015 14:25:16 +0000 Subject: [openssl-dev] [openssl.org #4145] Enhancement: patch to support s_client -starttls http In-Reply-To: References: Message-ID: Please note my typo identified by a dev at httpd, Yann... A little note, probably some missing == here: + else if (meth = TLSv1_2_client_method()) + BIO_printf(fbio, "Upgrade: TLS/1.2\r\n"); + else if (meth = TLSv1_1_client_method()) + BIO_printf(fbio, "Upgrade: TLS/1.1\r\n"); + else if (meth = TLSv1_client_method()) + BIO_printf(fbio, "Upgrade: TLS/1.0\r\n"); Revised patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: starttls-http-v2.patch Type: text/x-patch Size: 3677 bytes Desc: not available URL: From rt at openssl.org Wed Nov 18 15:24:51 2015 From: rt at openssl.org (=?UTF-8?B?w5Z6Z2FuLCBUb2xnYWhhbiBKb25hcw==?= via RT) Date: Wed, 18 Nov 2015 15:24:51 +0000 Subject: [openssl-dev] [openssl.org #4148] PCKS1 type 1 Padding check error In-Reply-To: <81BFD559DE725D46BA495E091789F8DD016AF6C497@MAILSERV2A.lorien.fkie.fgan.de> References: <81BFD559DE725D46BA495E091789F8DD016AF6C497@MAILSERV2A.lorien.fkie.fgan.de> Message-ID: Dear List, I have found a BUG in the function " RSA_padding_check_PKCS1_type_1 " The bug is reproducible in OpenSSL Versions 1.0.1e , 1.0.1p , 1.0.1k and also in 1.0.2d (these are the versions I've tried) . After Inspecting the source code the bug can still be found in the actual development branch. Description: When a correctly formatted PKCS1 Type 1 data string is given to the method " RSA_padding_check_PKCS1_type_1 " it always results in: OpenSSLError: Code:67567722 in file:rsa_pk1.c line:102. OpenSSLError: Error Message: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01 Even when the message was originally padded by the corresponding OpenSSL Padding Function " RSA_padding_add_PKCS1_type_1" the same error occurs. Cause: In the File crypto/rsa/rsa_pk1.c Following check is made to determine the Block type of the padding string const unsigned char *p; p=from; if ((num != (flen+1)) || (*(p++) != 01)) the pointer p is incremented after the check therefore p is always the first octet of the padded string. In the Case of PKCS1 type 1 padding always p=0, hence the error. Notes: Changing the check to if ((num != (flen+1)) || (*(++p) != 01)) results also in a failure since the next check of p expects p to be "0xff" . Fix: Adding an increment before the check: const unsigned char *p; p=from; p++; //NEW if ((num != (flen+1)) || (*(p++) != 01)) fixes the problem. Question: What does the the first part of the Check , check exactly ? Ie: num != (flen+1) num being rsa_size and flen the length of the buffer where the message is stored. Thanks Dipl.-Inf T. Jonas ?zgan Cyber Analysis & Defense Department Fraunhofer Institute for Communication, Information Processing and Ergonomics (FKIE) Fraunhoferstr. 20 | 53343 Wachtberg | Germany Tel: +49 228 9435-513 | Fax +49 228 9435-685 http://www.fkie.fraunhofer.de -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Nov 18 15:24:51 2015 From: rt at openssl.org (Michal Bozon via RT) Date: Wed, 18 Nov 2015 15:24:51 +0000 Subject: [openssl-dev] [openssl.org #4147] TSA: SHA-1 update In-Reply-To: <20151118130117.GA1978@carbon.cesnet.cz> References: <20151118130117.GA1978@carbon.cesnet.cz> Message-ID: OpenSSL TSA (ts) code is still using SHA-1 message digest algorithm, in even two ways: * as default message digest algo in the time-stamp query (by default) * in the time-stamp reply/token signature (hard-coded) This pull request attempts to fix it: https://github.com/openssl/openssl/pull/474 regards, Michal Bozon _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From bkaduk at akamai.com Wed Nov 18 17:12:59 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 18 Nov 2015 11:12:59 -0600 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> Message-ID: <564CB19B.6050605@akamai.com> On 11/18/2015 07:05 AM, Hubert Kario wrote: > So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to support > both relatively modern TLS with user certificates, preferably the newest > cryptosystems and hashes as well as the oldest ones that were > standardised and used. > > That means that old algorithms MUST remain in OpenSSL as supported > functionality. It may require linking to a specific library to make the > EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed > from it completely, definitely not before at least 50 years _after_ they > became obsolete and broken. > There seems to be a logical leap between these two paragraphs. Why is it necessary that OpenSSL be the only cryptographic library used by CAdES-A/etc. implementations? Is it in fact even necessary that only a single version of a single cryptographic library be used for such software? While OpenSSL may try to be a general-purpose crypto library, when a software has stringent or unusual crypto requirements, it seems reasonable that such a software may need to involve unusual implementations. I do not believe that OpenSSL has promised anywhere that it will support this sort of use case. -Ben From cpservicespb at gmail.com Wed Nov 18 17:46:46 2015 From: cpservicespb at gmail.com (CpServiceSPb .) Date: Wed, 18 Nov 2015 20:46:46 +0300 Subject: [openssl-dev] OpenSSL as OCSP server (responder) as multithreading daemon ! Message-ID: > We have no plans to do this. May be will put it into your plans ? > It would be nice to see something like this as a new open-source project. I am for that by both hands. Burt unfortunatelly I am not a well skilled programmer/developer and I will not do it. I can give the task for that for developers only. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Nov 18 17:50:22 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 18 Nov 2015 17:50:22 +0000 Subject: [openssl-dev] OpenSSL as OCSP server (responder) as multithreading daemon ! In-Reply-To: References: Message-ID: <4367dc53e663492faf442774dac2532c@usma1ex-dag1mb1.msg.corp.akamai.com> ? > We have no plans to do this. May be will put it into your plans ? Doubtful. We have lots of other work to do. Writing a full-strength database-backed OCSP responder is outside of our interests. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hkario at redhat.com Wed Nov 18 17:57:49 2015 From: hkario at redhat.com (Hubert Kario) Date: Wed, 18 Nov 2015 18:57:49 +0100 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <564CB19B.6050605@akamai.com> References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> Message-ID: <4855989.nphBNJ5Ttk@pintsize.usersys.redhat.com> On Wednesday 18 November 2015 11:12:59 Benjamin Kaduk wrote: > On 11/18/2015 07:05 AM, Hubert Kario wrote: > > So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to > > support both relatively modern TLS with user certificates, > > preferably the newest cryptosystems and hashes as well as the > > oldest ones that were standardised and used. > > > > That means that old algorithms MUST remain in OpenSSL as supported > > functionality. It may require linking to a specific library to make > > the EVP* with old ciphers, MACs, etc. work, but they MUST NOT be > > removed from it completely, definitely not before at least 50 years > > _after_ they became obsolete and broken. > > There seems to be a logical leap between these two paragraphs. Why is > it necessary that OpenSSL be the only cryptographic library used by > CAdES-A/etc. implementations? Is it in fact even necessary that only > a single version of a single cryptographic library be used for such > software? > > While OpenSSL may try to be a general-purpose crypto > library, when a software has stringent or unusual crypto > requirements, it seems reasonable that such a software may need to > involve unusual implementations. > > I do not believe that OpenSSL has promised anywhere that it will > support this sort of use case. From the main web page of project: The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, *full-featured*, and Open Source toolkit implementing the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols as well as a full-strength *general purpose* *cryptography library* . (emphasis mine) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From uri at ll.mit.edu Wed Nov 18 18:52:47 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 18 Nov 2015 18:52:47 +0000 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <564CB19B.6050605@akamai.com> References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> Message-ID: On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk" wrote: >On 11/18/2015 07:05 AM, Hubert Kario wrote: >> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to >>support >> both relatively modern TLS with user certificates, preferably the >>newest >> cryptosystems and hashes as well as the oldest ones that were >> standardised and used. >> >> That means that old algorithms MUST remain in OpenSSL as supported >> functionality. It may require linking to a specific library to make the >> EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed >> from it completely, definitely not before at least 50 years _after_ >>they >> became obsolete and broken. > >There seems to be a logical leap between these two paragraphs. Why is >it necessary that OpenSSL be the only cryptographic library used by >CAdES-A/etc. implementations? Because it used to be the only real game in town, and *people learned to rely upon it*. >Is it in fact even necessary that only a >single version of a single cryptographic library be used for such >software? No, of course not. But after letting people depend on this ?single cryptographic library? for many years, telling them ?too bad? isn?t very nice. >While OpenSSL may try to be a general-purpose crypto library, >when a software has stringent or unusual crypto requirements, it seems >reasonable that such a software may need to involve unusual >implementations. The requirements did not change. What changed was the maintainers expressing their desire to stop supporting some of them. >I do not believe that OpenSSL has promised anywhere that it will support >this sort of use case. Implicitly, by providing that kind of service for so long. And explicitly, as pointed out by Hubert: From the main web page of project: The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, *full-featured*, and Open Source toolkit implementing the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols as well as a full-strength *general purpose* *cryptography library* . -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From richmoore44 at gmail.com Wed Nov 18 20:05:22 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Wed, 18 Nov 2015 20:05:22 +0000 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <4855989.nphBNJ5Ttk@pintsize.usersys.redhat.com> References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <4855989.nphBNJ5Ttk@pintsize.usersys.redhat.com> Message-ID: On 18 November 2015 at 17:57, Hubert Kario wrote: > On Wednesday 18 November 2015 11:12:59 Benjamin Kaduk wrote: > > On 11/18/2015 07:05 AM, Hubert Kario wrote: > > > So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to > > > support both relatively modern TLS with user certificates, > > > preferably the newest cryptosystems and hashes as well as the > > > oldest ones that were standardised and used. > > > > > > That means that old algorithms MUST remain in OpenSSL as supported > > > functionality. It may require linking to a specific library to make > > > the EVP* with old ciphers, MACs, etc. work, but they MUST NOT be > > > removed from it completely, definitely not before at least 50 years > > > _after_ they became obsolete and broken. > > > There seems to be a logical leap between these two paragraphs. Why is > > it necessary that OpenSSL be the only cryptographic library used by > > CAdES-A/etc. implementations? Is it in fact even necessary that only > > a single version of a single cryptographic library be used for such > > software? > > > > While OpenSSL may try to be a general-purpose crypto > > library, when a software has stringent or unusual crypto > > requirements, it seems reasonable that such a software may need to > > involve unusual implementations. > > > > I do not believe that OpenSSL has promised anywhere that it will > > support this sort of use case. > > From the main web page of project: > > The OpenSSL Project is a collaborative effort to develop a robust, > commercial-grade, *full-featured*, and Open Source toolkit > implementing the Transport Layer Security (TLS) and Secure Sockets > Layer (SSL) protocols as well as a full-strength *general purpose* > *cryptography library* . > > (emphasis mine) > > ?I think now is the time for those who are going to provide the 50 year support to step up to the plate then. Saying "oh but we can get it for free for the next 50 years" doesn't work. I think your emphasis here is exactly right though, the aim is *general purpose*? you are most definitely describing an extremely specialised purpose that has unusual requirements. ?Cheers Rich.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Wed Nov 18 20:34:41 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 18 Nov 2015 14:34:41 -0600 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> Message-ID: <564CE0E1.2000203@akamai.com> On 11/18/2015 12:52 PM, Blumenthal, Uri - 0553 - MITLL wrote: > On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk" > wrote: > >> On 11/18/2015 07:05 AM, Hubert Kario wrote: >>> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to >>> support >>> both relatively modern TLS with user certificates, preferably the >>> newest >>> cryptosystems and hashes as well as the oldest ones that were >>> standardised and used. >>> >>> That means that old algorithms MUST remain in OpenSSL as supported >>> functionality. It may require linking to a specific library to make the >>> EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed >>> from it completely, definitely not before at least 50 years _after_ >>> they >>> became obsolete and broken. >> There seems to be a logical leap between these two paragraphs. Why is >> it necessary that OpenSSL be the only cryptographic library used by >> CAdES-A/etc. implementations? > Because it used to be the only real game in town, and *people learned to > rely upon it*. > >> Is it in fact even necessary that only a >> single version of a single cryptographic library be used for such >> software? > No, of course not. But after letting people depend on this ?single > cryptographic library? for many years, telling them ?too bad? isn?t very > nice. I guess I'm just having a hard time wrapping my head around why, upon hearing that the volunteer-run project is giving years' advance notice that certain features will be removed, the response is insistence that everything must remain supported forever, instead of using the advance notice to investigate alternatives. Volunteers should be allowed to ease up when they need to, after all. >> While OpenSSL may try to be a general-purpose crypto library, >> when a software has stringent or unusual crypto requirements, it seems >> reasonable that such a software may need to involve unusual >> implementations. > The requirements did not change. What changed was the maintainers > expressing their desire to stop supporting some of them. Surely the requirements for a general-purpose crypto library must change over time! In 1995, such a library did not (could not!) include AES support, whereas even by 2005 it would have been pretty essential to have. As the state of the art advances, the library must adapt to match, and removing components that are no longer widespread or essential seems a natural part of that adaptation. The requirements are not an append-only list. >> I do not believe that OpenSSL has promised anywhere that it will support >> this sort of use case. > Implicitly, by providing that kind of service for so long. And explicitly, > as pointed out by Hubert: Well, I see this thread as notice that the implicit support should no longer be taken for granted, with plenty of advance notice. > From the main web page of project: > > The OpenSSL Project is a collaborative effort to develop a robust, > commercial-grade, *full-featured*, and Open Source toolkit > implementing the Transport Layer Security (TLS) and Secure Sockets > Layer (SSL) protocols as well as a full-strength *general purpose* > *cryptography library* . > > That text reads as if it was originally drafted 10+ years ago, when "full-featured" meant "we support both encryption and decryption" as well as "we provide both export-grade and strong crypto". I'm sure we could put some updated text in if that would help clarify what exactly the goals of the project are. And, as Richard notes, general-purpose does not mean "usable for every possible specific use case under the sun", it means "usable for most common things", which to me does not include CAdES-A and the like. -Ben From beldmit at gmail.com Wed Nov 18 20:55:02 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 18 Nov 2015 23:55:02 +0300 Subject: [openssl-dev] PBE_UNICODE Message-ID: Hello OpenSSL Team, I use the openssl 1.0.2d. There is a commented out definition of the PBE_UNICODE define in the file pkcs12.h I expected it to be necessary for correct processing of the Cyrillic symbols in PKCS12 passwords, but my test shows that the password is correctly processed when the PBE_UNICODE is undefined and locale is set to ru_RU.utf8. Do I miss something or this variable and corresponding #ifdef may be eliminated? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From cpservicespb at gmail.com Wed Nov 18 23:01:14 2015 From: cpservicespb at gmail.com (CpServiceSPb .) Date: Thu, 19 Nov 2015 02:01:14 +0300 Subject: [openssl-dev] Fwd: OpenSSL as OCSP server (responder) as multithreading daemon ! Message-ID: >> We have no plans to do this. May be will put it into your plans ? > Doubtful. We have lots of other work to do. Writing a full-strength database-backed OCSP responder is outside of our interests. Ok. In such situation, can you add ability of using multiple -CA, -rkey, -rsigner parameters of trinity, at least ? That OSSL at Ocsp responder mode could handle arrived request through all specified parameters of trinity: -CA1, -rkey1, -rsigner1; -CA2, -rkey2, -rsigner3 and so on ? Besides, there is "Support Multiple CA certs in ocsp app" commit - https://github.com/akamai/openssl/commit/7f5ed141fef8509b589b5a5601f0ec2bf5e08faf Alex. P. S.: I am ready to make some donation for it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Nov 18 23:05:27 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 18 Nov 2015 23:05:27 +0000 Subject: [openssl-dev] Fwd: OpenSSL as OCSP server (responder) as multithreading daemon ! In-Reply-To: References: Message-ID: <3d7ccc00bf5c4ba19b4c0b4d1948b717@usma1ex-dag1mb1.msg.corp.akamai.com> ? Ok. In such situation, can you add ability of using multiple -CA, -rkey, -rsigner parameters of trinity, at least ? Perhjaps someone will contribute a patch? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Nov 19 02:12:44 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 19 Nov 2015 02:12:44 +0000 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <564CE0E1.2000203@akamai.com> References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <564CE0E1.2000203@akamai.com> Message-ID: <20151119021244.GG18315@mournblade.imrryr.org> On Wed, Nov 18, 2015 at 02:34:41PM -0600, Benjamin Kaduk wrote: > > No, of course not. But after letting people depend on this ?single > > cryptographic library? for many years, telling them ?too bad? isn?t very > > nice. > > I guess I'm just having a hard time wrapping my head around why, upon > hearing that the volunteer-run project is giving years' advance notice > that certain features will be removed, the response is insistence that > everything must remain supported forever, instead of using the advance > notice to investigate alternatives. Volunteers should be allowed to > ease up when they need to, after all. Culture-clash. Security culture says everything remotely weak must go, but release-engineering culture emphasizes compatibilty. The crypto library is more of a systems component, not a security component. The SSL library is more of a security component than a systems component, and has algorithm negotiation. For example, Linux never breaks user-land, you can do all kinds of things inside the kernel, but user-land software (for a fixed libc) that worked before is going to continue working on new kernels. Doing that since 1991 or so. SunOS libc implemented multiple ABIs to ensure application compatibility. Many other operating systems do likewise. For better or worse, libcrypto is part of that world. It is a building block library for whatever applications the users want to use it for. It is not a security technology in its own right. > Surely the requirements for a general-purpose crypto library must change > over time! Yes, by accretion. And "general-purpose" does not mean "the expected use-cases", it really means "general". > have. As the state of the art advances, the library must adapt to > match, and removing components that are no longer widespread or > essential seems a natural part of that adaptation. The requirements are > not an append-only list. Except that they are, just as Linux and libc provide an append-only set of interfaces. > > The OpenSSL Project is a collaborative effort to develop a robust, > > commercial-grade, *full-featured*, and Open Source toolkit > > implementing the Transport Layer Security (TLS) and Secure Sockets > > Layer (SSL) protocols as well as a full-strength *general purpose* > > *cryptography library* . > > > That text reads as if it was originally drafted 10+ years ago, when > "full-featured" meant "we support both encryption and decryption" as > well as "we provide both export-grade and strong crypto". I'm sure we > could put some updated text in if that would help clarify what exactly > the goals of the project are. And, as Richard notes, general-purpose > does not mean "usable for every possible specific use case under the > sun", it means "usable for most common things", which to me does not > include CAdES-A and the like. No, general purpose really means whatever purpose the user has in mind. The "most common things" is not "general purpose". -- Viktor. From tmraz at redhat.com Thu Nov 19 10:01:26 2015 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 19 Nov 2015 11:01:26 +0100 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151119021244.GG18315@mournblade.imrryr.org> References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <564CE0E1.2000203@akamai.com> <20151119021244.GG18315@mournblade.imrryr.org> Message-ID: <1447927286.13671.9.camel@redhat.com> On ?t, 2015-11-19 at 02:12 +0000, Viktor Dukhovni wrote: > On Wed, Nov 18, 2015 at 02:34:41PM -0600, Benjamin Kaduk wrote: > > > > No, of course not. But after letting people depend on this ?single > > > cryptographic library? for many years, telling them ?too bad? isn?t very > > > nice. > > > > I guess I'm just having a hard time wrapping my head around why, upon > > hearing that the volunteer-run project is giving years' advance notice > > that certain features will be removed, the response is insistence that > > everything must remain supported forever, instead of using the advance > > notice to investigate alternatives. Volunteers should be allowed to > > ease up when they need to, after all. > > Culture-clash. Security culture says everything remotely weak must > go, but release-engineering culture emphasizes compatibilty. The > crypto library is more of a systems component, not a security > component. The SSL library is more of a security component than > a systems component, and has algorithm negotiation. What about some reasonable middle ground? 1. remove all assembler implementations of not-current crypto 2. remove all references of it from the libssl 3. remove the respective EVP_add_cipher(), EVP_add_digest(),... from the OpenSSL_add* functions so the users have to explicitly add these to use them automatically. This way it is ensured that normal signature validation does not allow for these obsolete hashes to be used, etc. It is questionable whether it would be also good idea to disable the active operations - i.e. encryption for legacy ciphers and signature creation for legacy combinations of signing algorithms and hashes. In future it might be even reasonable to move the implementations into the libcryptolegacy.so however I am not sure this change is worth it for 1.1.0. I believe the maintenance costs for pure C implementations in such separate libcryptolegacy or even in the main C library would be quite minimal. I would also expect the users of such legacy code to step up with sharing the maintenance costs. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) From hkario at redhat.com Thu Nov 19 12:59:05 2015 From: hkario at redhat.com (Hubert Kario) Date: Thu, 19 Nov 2015 13:59:05 +0100 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <564CE0E1.2000203@akamai.com> References: <564CE0E1.2000203@akamai.com> Message-ID: <48295696.1iMcmaPotz@pintsize.usersys.redhat.com> On Wednesday 18 November 2015 14:34:41 Benjamin Kaduk wrote: > On 11/18/2015 12:52 PM, Blumenthal, Uri - 0553 - MITLL wrote: > > On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk" > > > > wrote: > >> On 11/18/2015 07:05 AM, Hubert Kario wrote: > >>> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to > >>> support > >>> both relatively modern TLS with user certificates, preferably the > >>> newest > >>> cryptosystems and hashes as well as the oldest ones that were > >>> standardised and used. > >>> > >>> That means that old algorithms MUST remain in OpenSSL as supported > >>> functionality. It may require linking to a specific library to > >>> make the EVP* with old ciphers, MACs, etc. work, but they MUST > >>> NOT be removed from it completely, definitely not before at least > >>> 50 years _after_ they > >>> became obsolete and broken. > >> > >> There seems to be a logical leap between these two paragraphs. Why > >> is it necessary that OpenSSL be the only cryptographic library > >> used by CAdES-A/etc. implementations? > > > > Because it used to be the only real game in town, and *people > > learned to rely upon it*. > > > >> Is it in fact even necessary that only a > >> single version of a single cryptographic library be used for such > >> software? > > > > No, of course not. But after letting people depend on this ?single > > cryptographic library? for many years, telling them ?too bad? isn?t > > very nice. > > I guess I'm just having a hard time wrapping my head around why, upon > hearing that the volunteer-run project is giving years' advance notice > that certain features will be removed, the response is insistence > that everything must remain supported forever, instead of using the > advance notice to investigate alternatives. Volunteers should be > allowed to ease up when they need to, after all. not everything If there was a queue to axe MD5 and SHA-1 signatures, 1DES ciphers, RC4 and export grade ciphers in libssl, you can be sure you'll find me at front of it we already removed SSLv2 from 1.1.0 and nobody really argued that it needs to stay But libcrypto needs to support legacy stuff because it needs to handle data at rest, not only data in transit. Those two are completely different worlds. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From uri at ll.mit.edu Thu Nov 19 15:39:52 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 19 Nov 2015 15:39:52 +0000 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <1447927286.13671.9.camel@redhat.com> References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <564CE0E1.2000203@akamai.com> <20151119021244.GG18315@mournblade.imrryr.org> <1447927286.13671.9.camel@redhat.com> Message-ID: On 11/19/15, 5:01 , "openssl-dev on behalf of Tomas Mraz" wrote: >On ?t, 2015-11-19 at 02:12 +0000, Viktor Dukhovni wrote: >> On Wed, Nov 18, 2015 at 02:34:41PM -0600, Benjamin Kaduk wrote: >> >>> I guess I'm just having a hard time wrapping my head around why, upon >> > hearing that the volunteer-run project is giving years' advance notice >> > that certain features will be removed, the response is insistence that >> > everything must remain supported forever, instead of using the advance >> > notice to investigate alternatives. Volunteers should be allowed to >> > ease up when they need to, after all. >> >> Culture-clash. Security culture says everything remotely weak must >> go, but release-engineering culture emphasizes compatibilty. The >> crypto library is more of a systems component, not a security >> component. The SSL library is more of a security component than >> a systems component, and has algorithm negotiation. > >What about some reasonable middle ground? >1. remove all assembler implementations of not-current crypto Yes, certainly. Legacy stuff is supposed to work. It may work slower. >2. remove all references of it from the libssl Yes, certainly. After all, this is where most of the threats and risks live. >3. remove the respective EVP_add_cipher(), EVP_add_digest(),... from the >OpenSSL_add* functions so the users have to explicitly add these to use >them automatically. Probably yes. Cannot judge the full impact off-hand, but it makes sense. >In future it might be even reasonable to move the implementations into >the libcryptolegacy.so however I am not sure this change is worth it for >1.1.0. I doubt that such a split would make sense. > >I believe the maintenance costs for pure C implementations in such >separate libcryptolegacy or even in the main C library would be quite >minimal. 100% concur, based on my experience maintaining code (going back enough decades to know :). >I would also expect the users of such legacy code to step up >with sharing the maintenance costs. Possibly. Though, as was pointed out, it is often unclear if you are or are not a user - can you tell for certain what crypto mechanisms (if any) protect your archives going back to the oldest one you keep? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From richmoore44 at gmail.com Thu Nov 19 16:36:09 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Thu, 19 Nov 2015 16:36:09 +0000 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <564CE0E1.2000203@akamai.com> <20151119021244.GG18315@mournblade.imrryr.org> <1447927286.13671.9.camel@redhat.com> Message-ID: On 19 November 2015 at 15:39, Blumenthal, Uri - 0553 - MITLL wrote: > > > >I believe the maintenance costs for pure C implementations in such > >separate libcryptolegacy or even in the main C library would be quite > >minimal. > > 100% concur, based on my experience maintaining code (going back enough > decades to know :). > > ?Heh. I actually tested building all releases of openssl after 0.9.7 a few months back - several refuse to build with the default options on 64 bit. In addition my experience shows that compilers get stricter over time, so old code will general need changes to work with newer compilers (even when you're only talking over a relatively short period such as 5 years). Now if this code were included in openssl but disabled by default then these problems would exist but simply be hidden until someone tried to use it. Given the user would then have to fix them (since no one else cares about their favourite dead algorithm) I don't really see what advantage having the code in the main tree offers. Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Thu Nov 19 16:56:51 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 19 Nov 2015 16:56:51 +0000 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <564CE0E1.2000203@akamai.com> <20151119021244.GG18315@mournblade.imrryr.org> <1447927286.13671.9.camel@redhat.com> Message-ID: > ?Heh. I actually tested building all releases of openssl after 0.9.7 a few > months back - several refuse to build with the default options on 64 bit. In > addition my experience shows that compilers get stricter over time, so old > code will general need changes to work with newer compilers (even when you're > only talking over a relatively short period such as 5 years). Now if this code > were included in openssl but disabled by default then these problems would > exist but simply be hidden until someone tried to use it. Given the user would > then have to fix them (since no one else cares about their favourite dead > algorithm) I don't really see what advantage having the code in the main tree > offers. I did not say ?no maintenance costs?. I said that I concur that the maintenance costs for such code would be minimal, which usually it is. I?m against ?disabling by default?. Removing access to such code from libssl is OK, and the correct thing to do from the security point of view. Removing from libcrypto is bad, and enough people here explained why well enough to avoid repeating the reasons. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From richmoore44 at gmail.com Thu Nov 19 17:07:38 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Thu, 19 Nov 2015 17:07:38 +0000 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <564CE0E1.2000203@akamai.com> <20151119021244.GG18315@mournblade.imrryr.org> <1447927286.13671.9.camel@redhat.com> Message-ID: On 19 November 2015 at 16:56, Blumenthal, Uri - 0553 - MITLL wrote: > ?Heh. I actually tested building all releases of openssl after 0.9.7 a few > months back - several refuse to build with the default options on 64 bit. > In addition my experience shows that compilers get stricter over time, so > old code will general need changes to work with newer compilers (even when > you're only talking over a relatively short period such as 5 years). Now if > this code were included in openssl but disabled by default then these > problems would exist but simply be hidden until someone tried to use it. > Given the user would then have to fix them (since no one else cares about > their favourite dead algorithm) I don't really see what advantage having > the code in the main tree offers. > > > I did not say ?no maintenance costs?. I said that I concur that the > maintenance costs for such code would be *minimal*, which usually it is. > > I?m against ?disabling by default?. Removing access to such code from > libssl is OK, and the correct thing to do from the security point of view. > Removing from libcrypto is bad, and enough people here explained why well > enough to avoid repeating the reasons. > ?Yes, but a several people (including me) disagree with you. And one of the options that has been suggested is to keep the code but have it disabled by default. Rich. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Thu Nov 19 17:18:41 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 19 Nov 2015 17:18:41 +0000 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <564CE0E1.2000203@akamai.com> <20151119021244.GG18315@mournblade.imrryr.org> <1447927286.13671.9.camel@redhat.com> Message-ID: >> I did not say ?no maintenance costs?. I said that I concur that the >> maintenance costs for such code would be minimal, which usually it is. >> >> I?m against ?disabling by default?. Removing access to such code from libssl >> is OK, and the correct thing to do from the security point of view. Removing >> from libcrypto is bad, and enough people here explained why well enough to >> avoid repeating the reasons. > > ?Yes, but a several people (including me) disagree with you. I know. > And one of the options that has been suggested is to keep the code but have it > disabled by default. I know. And I expressed my (negative) opinion of this option, which is better than completely wiping the code, but not by very much ? as you correctly pointed out. Still, at least this way user wouldn?t have to chase down the source files of an old algorithm. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From openssl-users at dukhovni.org Thu Nov 19 19:13:22 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 19 Nov 2015 19:13:22 +0000 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <1447927286.13671.9.camel@redhat.com> References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <564CE0E1.2000203@akamai.com> <20151119021244.GG18315@mournblade.imrryr.org> <1447927286.13671.9.camel@redhat.com> Message-ID: <20151119191322.GN18315@mournblade.imrryr.org> On Thu, Nov 19, 2015 at 11:01:26AM +0100, Tomas Mraz wrote: > 3. remove the respective EVP_add_cipher(), EVP_add_digest(),... from the > OpenSSL_add* functions so the users have to explicitly add these to use > them automatically. This does not work. Often the code that calls OpenSSL_add_all_algorithms() is not the code that knows which algorithms will be used (think scripting languages). Having a single call that adds all the algorithms or just the non-legacy algorithms can work, hance Matt's suggestion of a #define that selects between two implementations, and requires linking with the legacy library. -- Viktor. From openssl-users at dukhovni.org Thu Nov 19 19:28:53 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 19 Nov 2015 19:28:53 +0000 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <564CE0E1.2000203@akamai.com> <20151119021244.GG18315@mournblade.imrryr.org> <1447927286.13671.9.camel@redhat.com> Message-ID: <20151119192853.GO18315@mournblade.imrryr.org> On Thu, Nov 19, 2015 at 05:07:38PM +0000, Richard Moore wrote: >?Yes, but a several people (including me) disagree with you. And one of the > options that has been suggested is to keep the code but have it disabled by > default. Note, we're talking about "disabled" as opposed to "not compiled". Stuff that's not compiled by default tends to not get tested, and breaks silently when it is needed. That's not terribly useful. (Yes, I know about RC5, which is not compiled by default for IPR reasons. Distributions that have never shipped IDEA compiled-in can disable it downstream). This means that absent explicit compile-time directives, the EVP interface will not expose the legacy algorithms. Middleware that provides general-purpose crypto interfaces on top of OpenSSL to other software will need to enable the legacy algorithms. I am not convinced that making people jump through the extra hoops would be worth the effort on our part and theirs. Whom would we be helping? The simplest thing to do is to make legacy libcrypto code maximally maintainable, and if removing assembly support does that, than we do that. Beyond that, do nothing. What algorithms people use on their own data is their choice and risk decision not ours. -- Viktor. From richmoore44 at gmail.com Thu Nov 19 20:15:49 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Thu, 19 Nov 2015 20:15:49 +0000 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151119192853.GO18315@mournblade.imrryr.org> References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <564CE0E1.2000203@akamai.com> <20151119021244.GG18315@mournblade.imrryr.org> <1447927286.13671.9.camel@redhat.com> <20151119192853.GO18315@mournblade.imrryr.org> Message-ID: On 19 November 2015 at 19:28, Viktor Dukhovni wrote: > On Thu, Nov 19, 2015 at 05:07:38PM +0000, Richard Moore wrote: > > >?Yes, but a several people (including me) disagree with you. And one of > the > > options that has been suggested is to keep the code but have it disabled > by > > default. > > Note, we're talking about "disabled" as opposed to "not compiled". > Stuff that's not compiled by default tends to not get tested, and > breaks silently when it is needed. That's not terribly useful. > ?I haven't seen anything that suggests that actually. ?In fact my assumption is the opposite of yours. > (Yes, I know about RC5, which is not compiled by default for IPR > reasons. Distributions that have never shipped IDEA compiled-in > can disable it downstream). > > This means that absent explicit compile-time directives, the EVP > interface will not expose the legacy algorithms. Middleware that > provides general-purpose crypto interfaces on top of OpenSSL to > other software will need to enable the legacy algorithms. > > I am not convinced that making people jump through the extra hoops > would be worth the effort on our part and theirs. Whom would we > be helping? > ?Again, since the old middleware would need to change? either way, I don't see why the baggage should be brought along. > The simplest thing to do is to make legacy libcrypto code maximally > maintainable, and if removing assembly support does that, than we > do that. Beyond that, do nothing. What algorithms people use on > their own data is their choice and risk decision not ours. > > ?The simplest thing depends on your point of view. The simplest thing if you only care about openssl is to remove it, however the simplest thing if you only care about an end product that depends on some weird feature is to change nothing. You can't just make an absolute statement, as usual there are trade-offs and work for different people. ? ?Cheers Rich.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From appro at openssl.org Thu Nov 19 22:16:23 2015 From: appro at openssl.org (Andy Polyakov) Date: Thu, 19 Nov 2015 23:16:23 +0100 Subject: [openssl-dev] PBE_UNICODE In-Reply-To: References: Message-ID: <564E4A37.9010104@openssl.org> Hi, > I use the openssl 1.0.2d. > > There is a commented out definition of the PBE_UNICODE define in the > file pkcs12.h > I expected it to be necessary for correct processing of the Cyrillic > symbols in PKCS12 passwords, but my test shows that the password is > correctly processed when the PBE_UNICODE is undefined and locale is set > to ru_RU.utf8. > > Do I miss something or this variable and corresponding #ifdef may be > eliminated? What is "correctly"? PKCS12 is about interoperability and just because it's consistent with itself doesn't automatically mean it's actually interoperable. The way I read PKCS12 the string should be big-endian UTF-16 one. But what happens now? The string simply gets expanded as if it was plain ASCII. But is it right for UTF8 string that you're surely passing? No, correct procedure should be to convert it to wchar_t and then ensure correct endianness. In other words attempt to pass non-ASCII string at command line or prompt would not do the right thing. But it should also be recognized that deploying mbrtowc in _asc would only be part of the solution. Because interoperability is also about multiple operating systems. I mean we have to consider what happens on other OS, e.g. Windows. And on Windows it's even worse. As it stands now even passing non-ASCII strings as command-line argument [and presumably at prompt] is not an option. Bottom line is that one has to draw conclusion that non-ASCII characters are effectively not supported in pkcs12 utility. Regardless locale. Application programmer can get it right by sticking to _uni interface and performing due conversion to big-endian UTF-16 in own application. From jaroslav.imrich at gmail.com Fri Nov 20 07:47:46 2015 From: jaroslav.imrich at gmail.com (Jaroslav Imrich) Date: Fri, 20 Nov 2015 08:47:46 +0100 Subject: [openssl-dev] [openssl.org #4147] TSA: SHA-1 update In-Reply-To: References: <20151118130117.GA1978@carbon.cesnet.cz> Message-ID: Similar patch [0] is waiting for inclusion since 2010. Good luck :) [0] https://rt.openssl.org/Ticket/Display.html?id=2145 Regards, Jaroslav On Wed, Nov 18, 2015 at 4:24 PM, Michal Bozon via RT wrote: > OpenSSL TSA (ts) code is still using SHA-1 message digest algorithm, > in even two ways: > > * as default message digest algo in the time-stamp query (by default) > * in the time-stamp reply/token signature (hard-coded) > > This pull request attempts to fix it: > https://github.com/openssl/openssl/pull/474 > > > regards, > Michal Bozon > > _______________________________________________ > openssl-bugs-mod mailing list > openssl-bugs-mod at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Nov 20 07:48:01 2015 From: rt at openssl.org (Jaroslav Imrich via RT) Date: Fri, 20 Nov 2015 07:48:01 +0000 Subject: [openssl-dev] [openssl.org #4147] TSA: SHA-1 update In-Reply-To: References: <20151118130117.GA1978@carbon.cesnet.cz> Message-ID: Similar patch [0] is waiting for inclusion since 2010. Good luck :) [0] https://rt.openssl.org/Ticket/Display.html?id=2145 Regards, Jaroslav On Wed, Nov 18, 2015 at 4:24 PM, Michal Bozon via RT wrote: > OpenSSL TSA (ts) code is still using SHA-1 message digest algorithm, > in even two ways: > > * as default message digest algo in the time-stamp query (by default) > * in the time-stamp reply/token signature (hard-coded) > > This pull request attempts to fix it: > https://github.com/openssl/openssl/pull/474 > > > regards, > Michal Bozon > > _______________________________________________ > openssl-bugs-mod mailing list > openssl-bugs-mod at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From appro at openssl.org Fri Nov 20 09:08:59 2015 From: appro at openssl.org (Andy Polyakov) Date: Fri, 20 Nov 2015 10:08:59 +0100 Subject: [openssl-dev] PBE_UNICODE In-Reply-To: <564E4A37.9010104@openssl.org> References: <564E4A37.9010104@openssl.org> Message-ID: <564EE32B.4070706@openssl.org> > ... And on Windows it's even worse. As it stands now > even passing non-ASCII strings as command-line argument [and presumably > at prompt] is not an option. This is not entirely true. Whether or not one can pass non-ASCII strings as command-line argument is language-specific. Or rather code page-specific in Windowish. With Asian languages you're really out of luck, while smaller alphabets can work out (but not mixed) if system locale matches expectations. From beldmit at gmail.com Fri Nov 20 09:20:45 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 20 Nov 2015 12:20:45 +0300 Subject: [openssl-dev] PBE_UNICODE In-Reply-To: <564EE32B.4070706@openssl.org> References: <564E4A37.9010104@openssl.org> <564EE32B.4070706@openssl.org> Message-ID: Dear Andy, On Fri, Nov 20, 2015 at 12:08 PM, Andy Polyakov wrote: > > ... And on Windows it's even worse. As it stands now > > even passing non-ASCII strings as command-line argument [and presumably > > at prompt] is not an option. > > This is not entirely true. Whether or not one can pass non-ASCII strings > as command-line argument is language-specific. Or rather code > page-specific in Windowish. With Asian languages you're really out of > luck, while smaller alphabets can work out (but not mixed) if system > locale matches expectations. > I understand that there should be problems with Windows. So the test PKCS12 object was created using Windows using a GOST-providing CSP. I do not know whether the authors of the CSP have implemented their own mechanism of transforming the password or used any provided by the Windows system default. But in fact the openssl being built without defining the PBE_UNICODE macros was able to parse the test PKCS12. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From appro at openssl.org Fri Nov 20 10:48:22 2015 From: appro at openssl.org (Andy Polyakov) Date: Fri, 20 Nov 2015 11:48:22 +0100 Subject: [openssl-dev] PBE_UNICODE In-Reply-To: References: <564E4A37.9010104@openssl.org> <564EE32B.4070706@openssl.org> Message-ID: <564EFA76.2030804@openssl.org> On 11/20/15 10:20, Dmitry Belyavsky wrote: > Dear Andy, > > On Fri, Nov 20, 2015 at 12:08 PM, Andy Polyakov > wrote: > > > ... And on Windows it's even worse. As it stands now > > even passing non-ASCII strings as command-line argument [and presumably > > at prompt] is not an option. > > This is not entirely true. Whether or not one can pass non-ASCII strings > as command-line argument is language-specific. Or rather code > page-specific in Windowish. With Asian languages you're really out of > luck, while smaller alphabets can work out (but not mixed) if system > locale matches expectations. > > > I understand that there should be problems with Windows. To eliminate possibility of misunderstanding. Claim is not limited to problems with Windows, but that OpenSSL handles non-ASCII characters in apparently non-interoperable way. On all systems. I referred to Windows as complicating factor in the problem, not whole/separate problem. > So the test PKCS12 object was created using Windows using a > GOST-providing CSP. > > I do not know whether the authors of the CSP have implemented their own > mechanism of transforming the password or used any provided by the > Windows system default. What are chances that they too used same formally incorrect approach? > But in fact the openssl being built without defining the PBE_UNICODE > macros was able to parse the test PKCS12. Right. Doing otherwise will put burden of big-endian UTF-16 conversion on caller and chances that caller gets it right are low. > Thank you! ??? So suggestion is leave it as it is? Well, given the presented evidence doing the right thing should break things for you. But does it mean that one can/should be excused from getting things right? From beldmit at gmail.com Fri Nov 20 12:48:14 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 20 Nov 2015 15:48:14 +0300 Subject: [openssl-dev] PBE_UNICODE In-Reply-To: <564EFA76.2030804@openssl.org> References: <564E4A37.9010104@openssl.org> <564EE32B.4070706@openssl.org> <564EFA76.2030804@openssl.org> Message-ID: Dear Andy, On Fri, Nov 20, 2015 at 1:48 PM, Andy Polyakov wrote: > > > I understand that there should be problems with Windows. > > To eliminate possibility of misunderstanding. Claim is not limited to > problems with Windows, but that OpenSSL handles non-ASCII characters in > apparently non-interoperable way. On all systems. I referred to Windows > as complicating factor in the problem, not whole/separate problem. Yes, I understand it. > > > > So the test PKCS12 object was created using Windows using a > > GOST-providing CSP. > > > > I do not know whether the authors of the CSP have implemented their own > > mechanism of transforming the password or used any provided by the > > Windows system default. > > What are chances that they too used same formally incorrect approach? I think that they use the system method, if any, because it means they do not increase their work :-) > > > But in fact the openssl being built without defining the PBE_UNICODE > > macros was able to parse the test PKCS12. > > Right. Doing otherwise will put burden of big-endian UTF-16 conversion > on caller and chances that caller gets it right are low. Ok. > > > > Thank you! > > ??? So suggestion is leave it as it is? Well, given the presented > evidence doing the right thing should break things for you. But does it > mean that one can/should be excused from getting things right? https://tools.ietf.org/html/rfc7292#appendix-B.1 says: The underlying password-based encryption methods in PKCS #5 v2.1 view passwords (and salt) as being simple byte strings. ... What's left unspecified in the above paragraph is precisely where the byte string representing a password comes from. (This is not an issue with salt strings, since they are supplied as a password-based encryption (or authentication) parameter.) PKCS #5 v2.1 says: "[...] a password is considered to be an octet string of arbitrary length whose interpretation as a text string is unspecified. In the interest of interoperability, however, it is recommended that applications follow some common text encoding rules. ASCII and UTF-8 are two possibilities." In this specification, however, all passwords are created from BMPStrings with a NULL terminator. This means that each character in the original BMPString is encoded in 2 bytes in big-endian format (most-significant byte first). There are no Unicode byte order marks. The 2 bytes produced from the last character in the BMPString are followed by 2 additional bytes with the value 0x00. As I understand the text herein before, there is no ultimate specification. So I would prefer a set of options be specified by the caller with a reasonable default value. But as I do not have enough PKCS#12 from real-life sources, I can't predict this default value. Currently the openssl is in "works for me" state. To propose changes, I need to have a set of mismatching PKCS#12 files. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From appro at openssl.org Fri Nov 20 13:51:29 2015 From: appro at openssl.org (Andy Polyakov) Date: Fri, 20 Nov 2015 14:51:29 +0100 Subject: [openssl-dev] PBE_UNICODE In-Reply-To: References: <564E4A37.9010104@openssl.org> <564EE32B.4070706@openssl.org> <564EFA76.2030804@openssl.org> Message-ID: <564F2561.8050300@openssl.org> >> > I do not know whether the authors of the CSP have implemented their own >> > mechanism of transforming the password or used any provided by the >> > Windows system default. >> >> What are chances that they too used same formally incorrect approach? > > I think that they use the system method, if any, because it means they > do not increase their work :-) But there are couple of ways to do it with "system methods", and as far as I can tell neither should be interoperable with what OpenSSL pkcs12 command-line utility does... >> ??? So suggestion is leave it as it is? Well, given the presented >> evidence doing the right thing should break things for you. But does it >> mean that one can/should be excused from getting things right? > > https://tools.ietf.org/html/rfc7292#appendix-B.1 says: > > In this specification, however, all passwords are created from > BMPStrings with a NULL terminator. This means that each character in > the original BMPString is encoded in 2 bytes in big-endian format > (most-significant byte first). There are no Unicode byte order > marks. The 2 bytes produced from the last character in the BMPString > are followed by 2 additional bytes with the value 0x00. > > As I understand the text herein before, there is no ultimate specification. Correct. At the same time it should be noted that there is explicit reference to 2-byte encoding and Unicode. Well, one can argue that when they mention Unicode they refer to [lack of] byte order mark, and byte order mark only, and it has nothing to do with what that 2nd byte is used for. [Or shall we say "1st" as we are looking at big-endian?] But at the same time they don't say that the additional byte has to be zero. The only sensible and natural thing to do is to use these 2 bytes for storing UTF-16 character, not to mechanically inject zeros into UTF-8 encoded string as now... Of course one can say that latter, essentially unnatural way, is de-facto standard and we are stuck with it. But that would have to mean that it has to be harmonized on Windows. I refer to how OpenSSL pkcs12 works on Windows, not what somebody else does. In other words there is a dilemma. A. Choose what is right thing to do and act accordingly. B. Accept status quo with Unix as reference and harmonize Windows. Alternative to dilemma is to explicitly disclaim support for non-ASCII characters in pkcs12 utility. From rt at openssl.org Fri Nov 20 13:55:14 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 20 Nov 2015 13:55:14 +0000 Subject: [openssl-dev] [openssl.org #4147] TSA: SHA-1 update In-Reply-To: <20151118130117.GA1978@carbon.cesnet.cz> References: <20151118130117.GA1978@carbon.cesnet.cz> Message-ID: On Wed Nov 18 15:24:50 2015, mxlbzn at gmail.com wrote: > OpenSSL TSA (ts) code is still using SHA-1 message digest algorithm, > in even two ways: > > * as default message digest algo in the time-stamp query (by default) > * in the time-stamp reply/token signature (hard-coded) > > This pull request attempts to fix it: > https://github.com/openssl/openssl/pull/474 > Addressed in a slightly different way merging #2145. Let me know of any problems. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Fri Nov 20 13:56:37 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 20 Nov 2015 13:56:37 +0000 Subject: [openssl-dev] [openssl.org #2145] [PATCH] New parameter "signing_digest" for TS module In-Reply-To: References: <0146510d35424ebfb267725d828f5168@DISIGEX.disig.local> Message-ID: On Thu Jul 03 00:37:19 2014, jaroslav.imrich at disig.sk wrote: > Thank you for the comment - I have moved the new field at the end of > the TS_RESP_CTX structure. > I have also introduced TS_SIGNING_DIGEST flag that should prevent > binary compatibility issues when application allocates TS_RESP_CTX > itself using older headers but uses a newer library - you have > mentioned this potential problem in #3285. > Patch was tested against master branch. > Now added with a few minor changes to master. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From beldmit at gmail.com Fri Nov 20 18:13:02 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 20 Nov 2015 21:13:02 +0300 Subject: [openssl-dev] PBE_UNICODE In-Reply-To: <564F2561.8050300@openssl.org> References: <564E4A37.9010104@openssl.org> <564EE32B.4070706@openssl.org> <564EFA76.2030804@openssl.org> <564F2561.8050300@openssl.org> Message-ID: Dear Andy, On Fri, Nov 20, 2015 at 4:51 PM, Andy Polyakov wrote: > > >> ??? So suggestion is leave it as it is? Well, given the presented > >> evidence doing the right thing should break things for you. But does it > >> mean that one can/should be excused from getting things right? > > > > https://tools.ietf.org/html/rfc7292#appendix-B.1 says: > > > > In this specification, however, all passwords are created from > > BMPStrings with a NULL terminator. This means that each character in > > the original BMPString is encoded in 2 bytes in big-endian format > > (most-significant byte first). There are no Unicode byte order > > marks. The 2 bytes produced from the last character in the BMPString > > are followed by 2 additional bytes with the value 0x00. > > > > As I understand the text herein before, there is no ultimate > specification. > > Correct. At the same time it should be noted that there is explicit > reference to 2-byte encoding and Unicode. Well, one can argue that when > they mention Unicode they refer to [lack of] byte order mark, and byte > order mark only, and it has nothing to do with what that 2nd byte is > used for. [Or shall we say "1st" as we are looking at big-endian?] But > at the same time they don't say that the additional byte has to be zero. > The only sensible and natural thing to do is to use these 2 bytes for > storing UTF-16 character, not to mechanically inject zeros into UTF-8 > encoded string as now... Of course one can say that latter, essentially > unnatural way, is de-facto standard and we are stuck with it. But that > would have to mean that it has to be harmonized on Windows. I refer to > how OpenSSL pkcs12 works on Windows, not what somebody else does. In > other words there is a dilemma. A. Choose what is right thing to do and > act accordingly. B. Accept status quo with Unix as reference and > harmonize Windows. Alternative to dilemma is to explicitly disclaim > support for non-ASCII characters in pkcs12 utility. > There is a specification in Russian, http://tk26.ru/methods/containers_v1/Addition_to_PKCS8&PKCS12_v1_0.pdf It says: "The password Psw should be represented in UTF-8 format without trailing zero byte and passed as the P element of the PBKDF2 algorithm" The test example was provide by the authors of specification. There are also examples in the document. May be it will be useful. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Fri Nov 20 18:45:34 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 20 Nov 2015 19:45:34 +0100 Subject: [openssl-dev] PBE_UNICODE In-Reply-To: <564E4A37.9010104@openssl.org> References: <564E4A37.9010104@openssl.org> Message-ID: <20151120184533.GA352@roeckx.be> On Thu, Nov 19, 2015 at 11:16:23PM +0100, Andy Polyakov wrote: > > The way I read PKCS12 the string should be big-endian UTF-16 one. [...] > Correct procedure should be to convert it to wchar_t and > then ensure correct endianness. Please note that wchar_t itself might not have any relation with UTF. You should explictly convert from the locale charmap to UTF16-BE. Depending on the OS, there are functions available to ask what the current encoding is and convert between encodings. Kurt From quanah at zimbra.com Fri Nov 20 19:19:37 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Fri, 20 Nov 2015 11:19:37 -0800 Subject: [openssl-dev] We're working on license changes In-Reply-To: <163E1478CFDCDCC602DCDD3C@[192.168.1.9]> References: <20150804131953.17788996.93059.15020@ll.mit.edu> <654e1a98c48e443e91c7412a03adefba@ustx2ex-dag1mb2.msg.corp.akamai.com> <163E1478CFDCDCC602DCDD3C@[192.168.1.9]> Message-ID: <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> --On Tuesday, August 04, 2015 3:35 PM -0700 Quanah Gibson-Mount wrote: Just curious -- Any update on this? Is OpenSSL going to use something GPLv2 compatible? etc. Thanks, Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From appro at openssl.org Fri Nov 20 19:30:56 2015 From: appro at openssl.org (Andy Polyakov) Date: Fri, 20 Nov 2015 20:30:56 +0100 Subject: [openssl-dev] PBE_UNICODE In-Reply-To: <20151120184533.GA352@roeckx.be> References: <564E4A37.9010104@openssl.org> <20151120184533.GA352@roeckx.be> Message-ID: <564F74F0.6040204@openssl.org> >> The way I read PKCS12 the string should be big-endian UTF-16 one. > [...] >> Correct procedure should be to convert it to wchar_t and >> then ensure correct endianness. > > Please note that wchar_t itself might not have any relation with > UTF. You should explictly convert from the locale charmap to > UTF16-BE. Right, it was kind of sloppy formulation. > Depending on the OS, there are functions available to ask what the > current encoding is and convert between encodings. And question also is who should be responsible for the conversion. For example in order to make it work you might have to mess up locale, and a library in general is hardly the right place, and libcrypto in particular is terrible place to do that. Nor does one want to create dependency on library like iconv, not in libcrypto. In other words I'd say that it's not unreasonable to specify which input do we expect in libcrypto and put whole responsibility to ensure that input is right on caller. Formally one can say nothing needs to be changed in libcrypto, indeed there is _asc and _uni, i.e. ASCII and verbatim implying big-endian UTF-16. Though this is not an excuse for not doing anything about pkcs12 command-line utility... At the same time one can still argue that since there is a convenience _asc interface, there ought to be convenience utf8 one (and as already implied not dependent on current locale?)... From rsalz at akamai.com Fri Nov 20 19:34:04 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 20 Nov 2015 19:34:04 +0000 Subject: [openssl-dev] We're working on license changes In-Reply-To: <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> References: <20150804131953.17788996.93059.15020@ll.mit.edu> <654e1a98c48e443e91c7412a03adefba@ustx2ex-dag1mb2.msg.corp.akamai.com> <163E1478CFDCDCC602DCDD3C@[192.168.1.9]> <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> Message-ID: <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> It's almost definitely going to be Apache v2. From appro at openssl.org Fri Nov 20 19:45:11 2015 From: appro at openssl.org (Andy Polyakov) Date: Fri, 20 Nov 2015 20:45:11 +0100 Subject: [openssl-dev] PBE_UNICODE In-Reply-To: References: <564E4A37.9010104@openssl.org> <564EE32B.4070706@openssl.org> <564EFA76.2030804@openssl.org> <564F2561.8050300@openssl.org> Message-ID: <564F7847.2060902@openssl.org> > There is a specification in > Russian, http://tk26.ru/methods/containers_v1/Addition_to_PKCS8&PKCS12_v1_0.pdf > > It says: > "The password Psw should be represented in UTF-8 format without trailing > zero byte and passed as the P element of the PBKDF2 algorithm" Yeah, but this describes specific case, and has no "effect" on it being not really specified in general case. > The test example was provide by the authors of specification. There are > also examples in the document. May be it will be useful. We are apparently talking about slightly different things. Well, they are somewhat related, but not quite the same. It's just additional angle to cover. On related note I had no problem exporting pkcs12 file protected with password with non-ASCII letters from Windows and then failing to read it on Linux. From ssx at av8n.com Fri Nov 20 19:58:59 2015 From: ssx at av8n.com (John Denker) Date: Fri, 20 Nov 2015 12:58:59 -0700 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151119192853.GO18315@mournblade.imrryr.org> References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <564CE0E1.2000203@akamai.com> <20151119021244.GG18315@mournblade.imrryr.org> <1447927286.13671.9.camel@redhat.com> <20151119192853.GO18315@mournblade.imrryr.org> Message-ID: <564F7B83.8050902@av8n.com> On 11/19/2015 12:28 PM, Viktor Dukhovni wrote: > What algorithms people use on > their own data is their choice and risk decision not ours. I heartily agree with the sentiment. A low- or mid-level library is not the right place to be making and enshrining policy decisions. We can take yet another step in the same direction. There are several job descriptions: 1) Writing the library code. 2) Compiling the library code. This might be done by some distributor. This is where final decisions about #define options are made. 3) Linking against the compiled library and running the application. 4) Running the counterpart application on the other end of the communication line. You would think that the guy in job #3 would be in the best position to make policy decisions ... but sometimes even he doesn't get to make that decision, because of #4. It takes two to tango. It seems very likely that some people are using openssl to communicate with legacy devices that use "outdated" crypto primitives. -- There are /some/ cases where it is better to communicate in the clear than to encrypt badly. -- There are /some/ cases where it is better to not communicate at all than to encrypt badly. ++ Sometimes not! There is no such thing as absolute security, and sometimes an algorithm that would not withstand an "advanced persistent" attack might be good enough for some quick-and-dirty tactical purpose. To say the same thing another way: I am quite sure that many /persons/ on this list, if assigned to job #3 and/or job #4, could make wise decisions at those levels, based on information available at those levels. Indeed there are some persons on this list who wear all four hats simultaneously. So the question is, are there any representatives of category #3 who are willing to speak on behalf of /everybody/ in that category? If not, it seems this thread is asking a question that cannot be answered. To say the same thing yet another way, fundamentally we have a communication problem, or rather two separate communication problems: A) The experts on this list know that certain crypto primitives are "broken or outdated". This needs to be communicated to the people who are actually in a position to make and implement policy. B) There is some question as to whether users in the field have received message (A) and successfully ended all use of the deprecated primitives. It would be nice if the people who know the status could communicate this back to the developers. The problem is: It's not obvious that discussions on this list will solve either of these communication problems. It's very asymmetrical: If somebody squawks, you know you have a problem ... but the converse does not hold. Furthermore, it seems likely that the people who subscribe to this list have long since gotten message (A) ... but what about non-subscribers? There's a correlation there, the sort of correlation that makes it very perilous to extrapolate. From quanah at zimbra.com Fri Nov 20 20:37:13 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Fri, 20 Nov 2015 12:37:13 -0800 Subject: [openssl-dev] We're working on license changes In-Reply-To: <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20150804131953.17788996.93059.15020@ll.mit.edu> <654e1a98c48e443e91c7412a03adefba@ustx2ex-dag1mb2.msg.corp.akamai.com> <163E1478CFDCDCC602DCDD3C@[192.168.1.9]> <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <313961D7FE900DC0D4BE4654@[192.168.1.9]> --On Friday, November 20, 2015 7:34 PM +0000 "Salz, Rich" wrote: > It's almost definitely going to be Apache v2. Is there a possibility of releasing it under more than one license? Otherwise, I honestly don't really see the point of relicensing OpenSSL as moving to apache v2 does not resolve the primary problem with the OpenSSL license that currently exists. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From levitte at openssl.org Fri Nov 20 20:47:06 2015 From: levitte at openssl.org (Richard Levitte) Date: Fri, 20 Nov 2015 21:47:06 +0100 (CET) Subject: [openssl-dev] We're working on license changes In-Reply-To: <313961D7FE900DC0D4BE4654@[192.168.1.9]> References: <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> Message-ID: <20151120.214706.507338485957139502.levitte@openssl.org> In message <313961D7FE900DC0D4BE4654@[192.168.1.9]> on Fri, 20 Nov 2015 12:37:13 -0800, Quanah Gibson-Mount said: quanah> --On Friday, November 20, 2015 7:34 PM +0000 "Salz, Rich" quanah> -- wrote: quanah> quanah> > It's almost definitely going to be Apache v2. quanah> quanah> Is there a possibility of releasing it under more than one license? quanah> Otherwise, I honestly don't really see the point of relicensing quanah> OpenSSL as moving to apache v2 does not resolve the primary problem quanah> with the OpenSSL license that currently exists. I would like to point out that the GNU project talks about the Apache v2 license in positive terms: http://www.gnu.org/licenses/license-list.html -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Fri Nov 20 20:48:18 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 20 Nov 2015 20:48:18 +0000 Subject: [openssl-dev] We're working on license changes In-Reply-To: <313961D7FE900DC0D4BE4654@[192.168.1.9]> References: <20150804131953.17788996.93059.15020@ll.mit.edu> <654e1a98c48e443e91c7412a03adefba@ustx2ex-dag1mb2.msg.corp.akamai.com> <163E1478CFDCDCC602DCDD3C@[192.168.1.9]> <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> Message-ID: <7f3ea0caf6a74e028ca656e468dc9e12@usma1ex-dag1mb1.msg.corp.akamai.com> >Is there a possibility of releasing it under more than one license? Highly doubtful, at least not at first. > Otherwise, I honestly don't really see the point of relicensing OpenSSL as moving to apache v2 does not resolve the primary problem with the OpenSSL license that currently exists. Yes it does: the "advertising" clause and being a non-standard license. If you think the primary problem is GPL, well we disagree. And also, see this: http://www.apache.org/licenses/GPL-compatibility.html From quanah at zimbra.com Fri Nov 20 21:01:37 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Fri, 20 Nov 2015 13:01:37 -0800 Subject: [openssl-dev] We're working on license changes In-Reply-To: <20151120.214706.507338485957139502.levitte@openssl.org> References: <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> <20151120.214706.507338485957139502.levitte@openssl.org> Message-ID: --On Friday, November 20, 2015 9:47 PM +0100 Richard Levitte wrote: > I would like to point out that the GNU project talks about the Apache > v2 license in positive terms: > > http://www.gnu.org/licenses/license-list.html When dealing with the GPLv3, yes. However, it clearly notes the incompatibility with the GPLv2. Moving to a license that does not resolve the GPLv2 compatibility problem really doesn't help. I guess the overwhelming feedback from the community that the new license really needs to be GPLv2 compatible just went in one eye and out the other, so to speak. Re: Rich, yes removing the advertising clause is helpful, etc. Just move to plain BSD/MIT license then, and resolve all the issues. Or, does the community input that was received, that was consistently pointing out that a non-GPLv2 compatible license does not solve the fundamental problems with the current license going to continue to be blatantly ignored? --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From jifl at eCosCentric.com Fri Nov 20 21:28:58 2015 From: jifl at eCosCentric.com (Jonathan Larmour) Date: Fri, 20 Nov 2015 21:28:58 +0000 Subject: [openssl-dev] We're working on license changes In-Reply-To: <7f3ea0caf6a74e028ca656e468dc9e12@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20150804131953.17788996.93059.15020@ll.mit.edu> <654e1a98c48e443e91c7412a03adefba@ustx2ex-dag1mb2.msg.corp.akamai.com> <163E1478CFDCDCC602DCDD3C@[192.168.1.9]> <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> <7f3ea0caf6a74e028ca656e468dc9e12@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <564F909A.3070806@eCosCentric.com> On 20/11/15 20:48, Salz, Rich wrote: >> Is there a possibility of releasing it under more than one license? > > Highly doubtful, at least not at first. > >> Otherwise, I honestly don't really see the point of relicensing >> OpenSSL as moving to apache v2 does not resolve the primary problem >> with the OpenSSL license that currently exists. > > Yes it does: the "advertising" clause and being a non-standard > license. If you think the primary problem is GPL, well we disagree. > And also, see this: > http://www.apache.org/licenses/GPL-compatibility.html Although it's not compatible with GPLv2. Not everyone likes, or uses, or _can_ use GPLv3. And there's plenty of GPLv2 users (of which I am one) to prove the point: https://www.blackducksoftware.com/resources/data/top-20-open-source-licenses So a dual license still seems desirable to me. However, also, and as I said when this came up before, I don't believe the OpenSSL team is legally permitted to change the license as they do not hold the entire copyright. To change the licence, you need a copyright assignment or Contributor License Agreement from every individual or company who has contributed code to OpenSSL. You cannot change the terms of something you do not own. That is admittedly a significant hurdle to any change. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine From rsalz at akamai.com Fri Nov 20 21:31:18 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 20 Nov 2015 21:31:18 +0000 Subject: [openssl-dev] We're working on license changes In-Reply-To: <564F909A.3070806@eCosCentric.com> References: <20150804131953.17788996.93059.15020@ll.mit.edu> <654e1a98c48e443e91c7412a03adefba@ustx2ex-dag1mb2.msg.corp.akamai.com> <163E1478CFDCDCC602DCDD3C@[192.168.1.9]> <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> <7f3ea0caf6a74e028ca656e468dc9e12@usma1ex-dag1mb1.msg.corp.akamai.com> <564F909A.3070806@eCosCentric.com> Message-ID: <31778dd2c87d4e96953997784b887de9@usma1ex-dag1mb1.msg.corp.akamai.com> > you need a copyright assignment or Contributor License Agreement from every individual or company who has contributed code to OpenSSL. You cannot change the terms of something you do not own. That is admittedly a significant hurdle to any change. Yup. That's why it will take a while. From rt at openssl.org Fri Nov 20 21:38:18 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Fri, 20 Nov 2015 21:38:18 +0000 Subject: [openssl-dev] [openssl.org #4100] Overlapping memcpy arguments in bn_add.c In-Reply-To: <20151120213806.GA21344@roeckx.be> References: <8E115EC2-6D07-412F-9771-7C725F6CB080@trust-in-soft.com> <20151120213806.GA21344@roeckx.be> Message-ID: > 4/ in BN_usub, ap = a->d; and rp = r->d; > then the 2 pointers can be incremented, but an identical number of times > > 5/ then memcpy is called with rp and ap that are still aliases, which is undefined behavior The patch has been applied. Kurt From tshort at akamai.com Fri Nov 20 22:26:47 2015 From: tshort at akamai.com (Short, Todd) Date: Fri, 20 Nov 2015 22:26:47 +0000 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> Message-ID: <3CB9005A-76B1-4F42-BA72-DE46AB82C27D@akamai.com> While I am all for simplicity, I also think that removing functionality is a ?bad idea?. To reduce the support burden, deprecate the ciphers: 1. Under support, indicate that these ciphers will no longer receive fixes. 2. Remove any assembly implementations 3. Disable them by default. I suggest following the 80/20 rule (sometimes the 95/5 rule): Those ?who care? (the minority) about the ciphers can re-enable them and rebuild the library. Those ?who don?t care? (the majority) about the ciphers, should get the functionality that most people care about, basically SSL/TLS connectivity. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL > wrote: On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk" on behalf of bkaduk at akamai.com> wrote: On 11/18/2015 07:05 AM, Hubert Kario wrote: So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to support both relatively modern TLS with user certificates, preferably the newest cryptosystems and hashes as well as the oldest ones that were standardised and used. That means that old algorithms MUST remain in OpenSSL as supported functionality. It may require linking to a specific library to make the EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed from it completely, definitely not before at least 50 years _after_ they became obsolete and broken. There seems to be a logical leap between these two paragraphs. Why is it necessary that OpenSSL be the only cryptographic library used by CAdES-A/etc. implementations? Because it used to be the only real game in town, and *people learned to rely upon it*. Is it in fact even necessary that only a single version of a single cryptographic library be used for such software? No, of course not. But after letting people depend on this ?single cryptographic library? for many years, telling them ?too bad? isn?t very nice. While OpenSSL may try to be a general-purpose crypto library, when a software has stringent or unusual crypto requirements, it seems reasonable that such a software may need to involve unusual implementations. The requirements did not change. What changed was the maintainers expressing their desire to stop supporting some of them. I do not believe that OpenSSL has promised anywhere that it will support this sort of use case. Implicitly, by providing that kind of service for so long. And explicitly, as pointed out by Hubert: From the main web page of project: The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, *full-featured*, and Open Source toolkit implementing the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols as well as a full-strength *general purpose* *cryptography library* . _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalten at au1.ibm.com Sat Nov 21 02:09:53 2015 From: pwalten at au1.ibm.com (Peter Waltenberg) Date: Sat, 21 Nov 2015 02:09:53 +0000 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <3CB9005A-76B1-4F42-BA72-DE46AB82C27D@akamai.com> References: <3CB9005A-76B1-4F42-BA72-DE46AB82C27D@akamai.com>, <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> Message-ID: <201511210210.tAL2AvJi030500@d23av02.au.ibm.com> An HTML attachment was scrubbed... URL: From quanah at zimbra.com Sat Nov 21 02:21:38 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Fri, 20 Nov 2015 18:21:38 -0800 Subject: [openssl-dev] We're working on license changes In-Reply-To: <564F909A.3070806@eCosCentric.com> References: <20150804131953.17788996.93059.15020@ll.mit.edu> <654e1a98c48e443e91c7412a03adefba@ustx2ex-dag1mb2.msg.corp.akamai.com> <163E1478CFDCDCC602DCDD3C@[192.168.1.9]> <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> <7f3ea0caf6a74e028ca656e468dc9e12@usma1ex-dag1mb1.msg.corp.akamai.com> <564F909A.3070806@eCosCentric.com> Message-ID: <2AA4D8CBEF25CE20C81EE9E0@[192.168.1.9]> --On Friday, November 20, 2015 9:28 PM +0000 Jonathan Larmour wrote: > So a dual license still seems desirable to me. > > However, also, and as I said when this came up before, I don't believe the > OpenSSL team is legally permitted to change the license as they do not > hold the entire copyright. To change the licence, you need a copyright > assignment or Contributor License Agreement from every individual or > company who has contributed code to OpenSSL. You cannot change the terms > of something you do not own. That is admittedly a significant hurdle to > any change. Perhaps contributors, when approached by OpenSSL, can simly say they will not release their rights unless the project adopts a truly open license in the spirit of the original BSD style license minus the advertising clause. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From rt at openssl.org Sat Nov 21 03:12:28 2015 From: rt at openssl.org (Short, Todd via RT) Date: Sat, 21 Nov 2015 03:12:28 +0000 Subject: [openssl-dev] [openssl.org #4149] [PATCH] ssl_set_pkey() unnecessarily updates certificates In-Reply-To: <794E9936-04FF-45C6-8906-82F0B1BC2DCB@akamai.com> References: <794E9936-04FF-45C6-8906-82F0B1BC2DCB@akamai.com> Message-ID: Hello OpenSSL.org We have found the following issue in 1.0.2 and master branches of OpenSSL: ssl_set_pkey() unnecessarily updates certificates Some key types types (EC, DSA, DH, but not RSA) have separate parameters that are needed for correct operation. When ssl_set_pkey() is called (via SSL_use_PrivateKey), it copies these parameters from the newly set private key into the public key of the CERT structure. This could lead to a modification of the X509 structure while it is being used in another thread. This parameter copy is unconditional, and always occurs during ssl_set_pkey(). The proposed solution is to modify the copy routine EVP_PKEY_copy_parameters() to check for parameter equality via the EVP_PKEY_cmp_parameters() function before doing the actual copy. If the parameters match, then success is returned and no copy is performed. (But also check to see if the parameters are there before the compare.) This avoids unnecessary modification of the certificate structure and avoids the crash. The parameters may be copied on the first setting of the private key, but after that, the parameters will be equal and not copied any more. There is minimal locking around the SSL_use_PrivateKey() and other corresponding code, so adding additional locking would not suffice. A patch will be sent via github pull request, once a RT number is assigned. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From kurt at roeckx.be Sat Nov 21 11:50:15 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 21 Nov 2015 12:50:15 +0100 Subject: [openssl-dev] We're working on license changes In-Reply-To: References: <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> <20151120.214706.507338485957139502.levitte@openssl.org> Message-ID: <20151121115015.GA9953@roeckx.be> On Fri, Nov 20, 2015 at 01:01:37PM -0800, Quanah Gibson-Mount wrote: > --On Friday, November 20, 2015 9:47 PM +0100 Richard Levitte > wrote: > > >I would like to point out that the GNU project talks about the Apache > >v2 license in positive terms: > > > >http://www.gnu.org/licenses/license-list.html > > When dealing with the GPLv3, yes. However, it clearly notes the > incompatibility with the GPLv2. Moving to a license that does not resolve > the GPLv2 compatibility problem really doesn't help. I guess the > overwhelming feedback from the community that the new license really needs > to be GPLv2 compatible just went in one eye and out the other, so to speak. I would like to point out that GPLv2 also isn't compatible with GPLv3, and that that is causing just as much problems as the current OpenSSL license. Both the GPLv3 and Apache 2.0 have protection for patents, which is why it's not compatible with the GPLv2. If you look at the above page, they recommand the Apache 2.0 license instead of the MIT license just because of that. We are in a field were people do claim patents. So the question is if this patent protection is important for us or not. Kurt From rt at openssl.org Sat Nov 21 16:34:43 2015 From: rt at openssl.org (Ryan Barnett via RT) Date: Sat, 21 Nov 2015 16:34:43 +0000 Subject: [openssl-dev] [openssl.org #4150] bug: Makefile.shared has race condition with SYMLINK_SO when building in parallel In-Reply-To: References: Message-ID: The build-shared target depends on do_crypto and link-shared, which will be executed in parallel. do_crypto calls link_a.linux_shared -> link_a.gnu which does SYMLINK_SO; in parallel, link-shared calls symlink.linux_shared which also does SYMLINK_SO. Before the symlink is created, it is rm'ed, but there is a tiny chance that the second one is created after the rm has been called. Even replacing the rm with an ln -sf doesn't fix the operation since this isn't atomic operation. The errors seen are such as: ln: failed to create symbolic link 'libssl.so': File exists ln: creating symbolic link `libcrypto.so': File exists The depends need to be fixed up so that SYMLINK_SO isn't executed in parallel but I'm not able to see an easy solution to this problem. This was detected while utilizing Gentoo's parallel build patch [1] within the Buildroot project [2]. This issue occurs when building Openssl 1.0.2d for any Linux target that has shared library support. See discussion on the Gentoo's bug tracking as well [3]. [1] - https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/files/openssl-1.0.2d-parallel-build.patch [2] - http://lists.busybox.net/pipermail/buildroot/2015-November/144686.html [3 - https://bugs.gentoo.org/show_bug.cgi?id=566260 Thanks, -Ryan _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From quanah at zimbra.com Sat Nov 21 19:07:36 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Sat, 21 Nov 2015 11:07:36 -0800 Subject: [openssl-dev] We're working on license changes In-Reply-To: <20151121115015.GA9953@roeckx.be> References: <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> <20151120.214706.507338485957139502.levitte@openssl.org> <20151121115015.GA9953@roeckx.be> Message-ID: --On Saturday, November 21, 2015 12:50 PM +0100 Kurt Roeckx wrote: > I would like to point out that GPLv2 also isn't compatible with > GPLv3, and that that is causing just as much problems as the > current OpenSSL license. > > Both the GPLv3 and Apache 2.0 have protection for patents, which is > why it's not compatible with the GPLv2. If you look at the above > page, they recommand the Apache 2.0 license instead of the MIT > license just because of that. > > We are in a field were people do claim patents. So the question > is if this patent protection is important for us or not. So the MPLv2 is compatible with the APLv2. The MPLv2 is compatible with the GPLv2 and the APLv2 is copmatible with GPLv3. The MPLv2 has patent language along the same lines as the APLv2. I haven't looked into it and I am not a lawyer, but would it be possible to dual license via the MPLv2 and the APLv2? If so, that would keep the patent protections and allow both GPLv2 and GPLv3 compatibility. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From kurt at roeckx.be Sat Nov 21 19:24:22 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 21 Nov 2015 20:24:22 +0100 Subject: [openssl-dev] We're working on license changes In-Reply-To: References: <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> <20151120.214706.507338485957139502.levitte@openssl.org> <20151121115015.GA9953@roeckx.be> Message-ID: <20151121192422.GA29319@roeckx.be> On Sat, Nov 21, 2015 at 11:07:36AM -0800, Quanah Gibson-Mount wrote: > --On Saturday, November 21, 2015 12:50 PM +0100 Kurt Roeckx > wrote: > > > > >I would like to point out that GPLv2 also isn't compatible with > >GPLv3, and that that is causing just as much problems as the > >current OpenSSL license. > > > >Both the GPLv3 and Apache 2.0 have protection for patents, which is > >why it's not compatible with the GPLv2. If you look at the above > >page, they recommand the Apache 2.0 license instead of the MIT > >license just because of that. > > > >We are in a field were people do claim patents. So the question > >is if this patent protection is important for us or not. > > So the MPLv2 is compatible with the APLv2. The MPLv2 is compatible with the > GPLv2 and the APLv2 is copmatible with GPLv3. The MPLv2 has patent language > along the same lines as the APLv2. I haven't looked into it and I am not a > lawyer, but would it be possible to dual license via the MPLv2 and the > APLv2? If so, that would keep the patent protections and allow both GPLv2 > and GPLv3 compatibility. I think the answer to that is complicated. The safest way to look at this, at what most people seem to be doing, is that if it all ends up in 1 "program", all licenses must be complied with at the same time and so must be compatible. Kurt From quanah at zimbra.com Sat Nov 21 20:02:22 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Sat, 21 Nov 2015 12:02:22 -0800 Subject: [openssl-dev] We're working on license changes In-Reply-To: <20151121192422.GA29319@roeckx.be> References: <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> <20151120.214706.507338485957139502.levitte@openssl.org> <20151121115015.GA9953@roeckx.be> <20151121192422.GA29319@roeckx.be> Message-ID: --On Saturday, November 21, 2015 8:24 PM +0100 Kurt Roeckx wrote: >> So the MPLv2 is compatible with the APLv2. The MPLv2 is compatible with >> the GPLv2 and the APLv2 is copmatible with GPLv3. The MPLv2 has patent >> language along the same lines as the APLv2. I haven't looked into it >> and I am not a lawyer, but would it be possible to dual license via the >> MPLv2 and the APLv2? If so, that would keep the patent protections and >> allow both GPLv2 and GPLv3 compatibility. > > I think the answer to that is complicated. The safest way to look > at this, at what most people seem to be doing, is that if it all > ends up in 1 "program", all licenses must be complied with at the > same time and so must be compatible. That's an interesting take I've not encountered. Our legal office has us elect specifically which license we will be using when pulling in software with multiple licenses. For example: >>> amqp-client-3.5.0 This package, the RabbitMQ Java client library, is triple-licensed under the Mozilla Public License 1.1 ("MPL"), the GNU General Public License version 2 ("GPL") and the Apache License version 2 ("ASL"). For the MPL, please see LICENSE-MPL-RabbitMQ. For the GPL, please see LICENSE-GPL2. For the ASL, please see LICENSE-APACHE2. [PLEASE NOTE: ZIMBRA, INC. ELECTS TO USE AND DISTRIBUTE THIS COMPONENT UNDER THE TERMS OF THE Apache License, V2.0. PLEASE SEE THE APPENDIX TO REVIEW THE FULL TEXT OF ASL 2.0. THE ORIGINAL LICENSE TERMS ARE REPRODUCED BELOW ONLY AS A REFERENCE] (etc). Since you already cannot mix GPLv2 and GPLv3, then those who need openssl for GPLv2 reasons could elect to choose the MPLv2, and those who need openssl for GLPv3 reasons could elect to choose the APLv2. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From kurt at roeckx.be Sat Nov 21 21:14:37 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 21 Nov 2015 22:14:37 +0100 Subject: [openssl-dev] We're working on license changes In-Reply-To: References: <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> <20151120.214706.507338485957139502.levitte@openssl.org> <20151121115015.GA9953@roeckx.be> <20151121192422.GA29319@roeckx.be> Message-ID: <20151121211436.GA759@roeckx.be> On Sat, Nov 21, 2015 at 12:02:22PM -0800, Quanah Gibson-Mount wrote: > --On Saturday, November 21, 2015 8:24 PM +0100 Kurt Roeckx > wrote: > >>So the MPLv2 is compatible with the APLv2. The MPLv2 is compatible with > >>the GPLv2 and the APLv2 is copmatible with GPLv3. The MPLv2 has patent > >>language along the same lines as the APLv2. I haven't looked into it > >>and I am not a lawyer, but would it be possible to dual license via the > >>MPLv2 and the APLv2? If so, that would keep the patent protections and > >>allow both GPLv2 and GPLv3 compatibility. > > > >I think the answer to that is complicated. The safest way to look > >at this, at what most people seem to be doing, is that if it all > >ends up in 1 "program", all licenses must be complied with at the > >same time and so must be compatible. > > That's an interesting take I've not encountered. Our legal office has us > elect specifically which license we will be using when pulling in software > with multiple licenses. I think there was a misunderstanding of what I was trying to say. If you have software A with license B or C, and software D makes use of that with license E or F. If that in turn makes use of G with license H or I, you will need to find a combination of (B || C) && (E || F) && (H || I) where you have 3 license that are compatible, not just 2 from (B || C) && (E || F), and then 2 from (E || F) && (H || I). I hope that makes it more clear. Kurt From rsalz at akamai.com Sat Nov 21 22:07:36 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 21 Nov 2015 22:07:36 +0000 Subject: [openssl-dev] We're working on license changes In-Reply-To: References: <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> <20151120.214706.507338485957139502.levitte@openssl.org> <20151121115015.GA9953@roeckx.be> Message-ID: I don't see how MPL2 can have patent protection when it is the patent protection that cases GPL2 to be incompatible with APL2. >I have not looked into it and I am not a lawyer. Ah. From ben at links.org Sat Nov 21 22:09:51 2015 From: ben at links.org (Ben Laurie) Date: Sat, 21 Nov 2015 22:09:51 +0000 Subject: [openssl-dev] We're working on license changes In-Reply-To: <20151121211436.GA759@roeckx.be> References: <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> <20151120.214706.507338485957139502.levitte@openssl.org> <20151121115015.GA9953@roeckx.be> <20151121192422.GA29319@roeckx.be> <20151121211436.GA759@roeckx.be> Message-ID: On Sat, 21 Nov 2015 at 21:14 Kurt Roeckx wrote: > On Sat, Nov 21, 2015 at 12:02:22PM -0800, Quanah Gibson-Mount wrote: > > --On Saturday, November 21, 2015 8:24 PM +0100 Kurt Roeckx < > kurt at roeckx.be> > > wrote: > > >>So the MPLv2 is compatible with the APLv2. The MPLv2 is compatible > with > > >>the GPLv2 and the APLv2 is copmatible with GPLv3. The MPLv2 has patent > > >>language along the same lines as the APLv2. I haven't looked into it > > >>and I am not a lawyer, but would it be possible to dual license via the > > >>MPLv2 and the APLv2? If so, that would keep the patent protections and > > >>allow both GPLv2 and GPLv3 compatibility. > > > > > >I think the answer to that is complicated. The safest way to look > > >at this, at what most people seem to be doing, is that if it all > > >ends up in 1 "program", all licenses must be complied with at the > > >same time and so must be compatible. > > > > That's an interesting take I've not encountered. Our legal office has us > > elect specifically which license we will be using when pulling in > software > > with multiple licenses. > > I think there was a misunderstanding of what I was trying to say. > If you have software A with license B or C, and software D makes > use of that with license E or F. If that in turn makes use of G > with license H or I, you will need to find a combination of > (B || C) && (E || F) && (H || I) where you have 3 license that are > compatible, not just 2 from (B || C) && (E || F), and then 2 from > (E || F) && (H || I). > Well, now you put it that way, I have to disagree. Let's say: A and D are compatible because B and E are. D and G are compatible because F and H are. G and A are compatible because I and C are. Who has been harmed here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From quanah at zimbra.com Sat Nov 21 22:19:31 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Sat, 21 Nov 2015 14:19:31 -0800 Subject: [openssl-dev] We're working on license changes In-Reply-To: References: <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> <20151120.214706.507338485957139502.levitte@openssl.org> <20151121115015.GA9953@roeckx.be> Message-ID: <9A8898E5E607C42D910262D1@[192.168.1.9]> --On Saturday, November 21, 2015 10:07 PM +0000 "Salz, Rich" wrote: > I don't see how MPL2 can have patent protection when it is the patent > protection that cases GPL2 to be incompatible with APL2. MPL version 2.0 is compatible with both the Apache License[11] and by default "the GNU GPL version 2.0, the GNU LGPL version 2.1, the GNU AGPL version 3.0, and all later versions of those licenses". It would seem, then, that the MPLv2 covers all cases (GPLv2, GPLv3, etc). >> I have not looked into it and I am not a lawyer. Both contain a retaliation clause and a patent grant. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From rsalz at akamai.com Sat Nov 21 22:32:45 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 21 Nov 2015 22:32:45 +0000 Subject: [openssl-dev] We're working on license changes In-Reply-To: <9A8898E5E607C42D910262D1@[192.168.1.9]> References: <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> <20151120.214706.507338485957139502.levitte@openssl.org> <20151121115015.GA9953@roeckx.be> <9A8898E5E607C42D910262D1@[192.168.1.9]> Message-ID: <516a968dd51a40f2a43a306b7c2095aa@usma1ex-dag1mb1.msg.corp.akamai.com> Sorry, that answer -- quoting a claim -- does not answer my question. If the issue between APL and GPL2 is patent, then how can MPL2 address both? From kurt at roeckx.be Sat Nov 21 22:39:39 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 21 Nov 2015 23:39:39 +0100 Subject: [openssl-dev] We're working on license changes In-Reply-To: References: <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> <20151120.214706.507338485957139502.levitte@openssl.org> <20151121115015.GA9953@roeckx.be> <20151121192422.GA29319@roeckx.be> <20151121211436.GA759@roeckx.be> Message-ID: <20151121223939.GA5369@roeckx.be> On Sat, Nov 21, 2015 at 10:09:51PM +0000, Ben Laurie wrote: > On Sat, 21 Nov 2015 at 21:14 Kurt Roeckx wrote: > > > On Sat, Nov 21, 2015 at 12:02:22PM -0800, Quanah Gibson-Mount wrote: > > > --On Saturday, November 21, 2015 8:24 PM +0100 Kurt Roeckx < > > kurt at roeckx.be> > > > wrote: > > > >>So the MPLv2 is compatible with the APLv2. The MPLv2 is compatible > > with > > > >>the GPLv2 and the APLv2 is copmatible with GPLv3. The MPLv2 has patent > > > >>language along the same lines as the APLv2. I haven't looked into it > > > >>and I am not a lawyer, but would it be possible to dual license via the > > > >>MPLv2 and the APLv2? If so, that would keep the patent protections and > > > >>allow both GPLv2 and GPLv3 compatibility. > > > > > > > >I think the answer to that is complicated. The safest way to look > > > >at this, at what most people seem to be doing, is that if it all > > > >ends up in 1 "program", all licenses must be complied with at the > > > >same time and so must be compatible. > > > > > > That's an interesting take I've not encountered. Our legal office has us > > > elect specifically which license we will be using when pulling in > > software > > > with multiple licenses. > > > > I think there was a misunderstanding of what I was trying to say. > > If you have software A with license B or C, and software D makes > > use of that with license E or F. If that in turn makes use of G > > with license H or I, you will need to find a combination of > > (B || C) && (E || F) && (H || I) where you have 3 license that are > > compatible, not just 2 from (B || C) && (E || F), and then 2 from > > (E || F) && (H || I). > > > > Well, now you put it that way, I have to disagree. > > Let's say: > > A and D are compatible because B and E are. > D and G are compatible because F and H are. > G and A are compatible because I and C are. > > Who has been harmed here? Some people will argue that A is then covered by both B and C at the same time and you need to comply with both, it's no longer an option to use either B or C. The same goes for D being both E and F, and G being both H and I. If you drop the last line, because there is no direct link between A and G, you end up with just B, E, F and H you need to comply with at the same time. But some will argue that that is not good enough because they're all linked together. Kurt From ben at links.org Sat Nov 21 22:52:20 2015 From: ben at links.org (Ben Laurie) Date: Sat, 21 Nov 2015 22:52:20 +0000 Subject: [openssl-dev] We're working on license changes In-Reply-To: <20151121223939.GA5369@roeckx.be> References: <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> <20151120.214706.507338485957139502.levitte@openssl.org> <20151121115015.GA9953@roeckx.be> <20151121192422.GA29319@roeckx.be> <20151121211436.GA759@roeckx.be> <20151121223939.GA5369@roeckx.be> Message-ID: On Sat, 21 Nov 2015 at 22:39 Kurt Roeckx wrote: > On Sat, Nov 21, 2015 at 10:09:51PM +0000, Ben Laurie wrote: > > On Sat, 21 Nov 2015 at 21:14 Kurt Roeckx wrote: > > > > > On Sat, Nov 21, 2015 at 12:02:22PM -0800, Quanah Gibson-Mount wrote: > > > > --On Saturday, November 21, 2015 8:24 PM +0100 Kurt Roeckx < > > > kurt at roeckx.be> > > > > wrote: > > > > >>So the MPLv2 is compatible with the APLv2. The MPLv2 is compatible > > > with > > > > >>the GPLv2 and the APLv2 is copmatible with GPLv3. The MPLv2 has > patent > > > > >>language along the same lines as the APLv2. I haven't looked into > it > > > > >>and I am not a lawyer, but would it be possible to dual license > via the > > > > >>MPLv2 and the APLv2? If so, that would keep the patent > protections and > > > > >>allow both GPLv2 and GPLv3 compatibility. > > > > > > > > > >I think the answer to that is complicated. The safest way to look > > > > >at this, at what most people seem to be doing, is that if it all > > > > >ends up in 1 "program", all licenses must be complied with at the > > > > >same time and so must be compatible. > > > > > > > > That's an interesting take I've not encountered. Our legal office > has us > > > > elect specifically which license we will be using when pulling in > > > software > > > > with multiple licenses. > > > > > > I think there was a misunderstanding of what I was trying to say. > > > If you have software A with license B or C, and software D makes > > > use of that with license E or F. If that in turn makes use of G > > > with license H or I, you will need to find a combination of > > > (B || C) && (E || F) && (H || I) where you have 3 license that are > > > compatible, not just 2 from (B || C) && (E || F), and then 2 from > > > (E || F) && (H || I). > > > > > > > Well, now you put it that way, I have to disagree. > > > > Let's say: > > > > A and D are compatible because B and E are. > > D and G are compatible because F and H are. > > G and A are compatible because I and C are. > > > > Who has been harmed here? > > Some people will argue that A is then covered by both B and C at > the same time and you need to comply with both, Who is the "you" that needs to comply with both? All the complying has already been done. Only A, D and G need comply, and they do. > it's no longer an > option to use either B or C. The same goes for D being both E > and F, and G being both H and I. > > If you drop the last line, because there is no direct link between > A and G, you end up with just B, E, F and H you need to comply > with at the same time. But some will argue that that is not good > enough because they're all linked together. > > > Kurt > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From quanah at zimbra.com Sat Nov 21 23:10:49 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Sat, 21 Nov 2015 15:10:49 -0800 Subject: [openssl-dev] We're working on license changes In-Reply-To: <516a968dd51a40f2a43a306b7c2095aa@usma1ex-dag1mb1.msg.corp.akamai.com> References: <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> <20151120.214706.507338485957139502.levitte@openssl.org> <20151121115015.GA9953@roeckx.be> <9A8898E5E607C42D910262D1@[192.168.1.9]> <516a968dd51a40f2a43a306b7c2095aa@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: --On Saturday, November 21, 2015 10:32 PM +0000 "Salz, Rich" wrote: > Sorry, that answer -- quoting a claim -- does not answer my question. If > the issue between APL and GPL2 is patent, then how can MPL2 address both? The GNU folks clearly state that they are compatible: The reason appears to be that the MPLv2 *specifically* grants compatibility with the GPLv2+ as a part of its terms, whereas the APL does not. , see section 1.12 --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From rsalz at akamai.com Sat Nov 21 23:12:53 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 21 Nov 2015 23:12:53 +0000 Subject: [openssl-dev] We're working on license changes In-Reply-To: References: <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> <20151120.214706.507338485957139502.levitte@openssl.org> <20151121115015.GA9953@roeckx.be> <9A8898E5E607C42D910262D1@[192.168.1.9]> <516a968dd51a40f2a43a306b7c2095aa@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <5a6c037f348e42deb47894665153e9e0@usma1ex-dag1mb1.msg.corp.akamai.com> > The GNU folks clearly state that they are compatible: Interesting. We'll look at it. Thanks. Don't get your hopes up :) From quanah at zimbra.com Sat Nov 21 23:35:23 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Sat, 21 Nov 2015 15:35:23 -0800 Subject: [openssl-dev] We're working on license changes In-Reply-To: <5a6c037f348e42deb47894665153e9e0@usma1ex-dag1mb1.msg.corp.akamai.com> References: <91AF1E83E5B2373F111EB2B7@[192.168.1.9]> <5d6532303dab49b888e6c218d1c5d7e4@usma1ex-dag1mb1.msg.corp.akamai.com> <313961D7FE900DC0D4BE4654@[192.168.1.9]> <20151120.214706.507338485957139502.levitte@openssl.org> <20151121115015.GA9953@roeckx.be> <9A8898E5E607C42D910262D1@[192.168.1.9]> <516a968dd51a40f2a43a306b7c2095aa@usma1ex-dag1mb1.msg.corp.akamai.com> <5a6c037f348e42deb47894665153e9e0@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: --On Saturday, November 21, 2015 11:12 PM +0000 "Salz, Rich" wrote: > >> The GNU folks clearly state that they are compatible: > > Interesting. We'll look at it. Thanks. > > Don't get your hopes up :) Thank you for being willing to take the time to look into it. :) If compatibilty with the GPLv2 and GPLv3 could be resolved with relicensing while keeping the patent portions in place, it would be a major win for the community. :) --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From rt at openssl.org Sun Nov 22 11:25:56 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Sun, 22 Nov 2015 11:25:56 +0000 Subject: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options In-Reply-To: <20151122112553.GA20758@roeckx.be> References: <564B39A2.9040807@netbsd.org> <20151122112553.GA20758@roeckx.be> Message-ID: On Tue, Nov 17, 2015 at 05:43:45PM +0000, Richard PALO via RT wrote: > I'd like to propose the attached patch to 1.0.2d which avoids problems > with strict ISO conforming compiler/options, which do not define 'sun' only > '__sun' as usual... such as gcc/clang -std=c99 > > This affects the build itself, but also any user of openssl/opensslconf.h I've commited only the part that applied to the master branch, but fixed that in all the branches. Please let me know if you need other changes in the stable branches. Kurt From rt at openssl.org Sun Nov 22 12:32:04 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Sun, 22 Nov 2015 12:32:04 +0000 Subject: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options In-Reply-To: <5651B5BF.4050102@openssl.org> References: <564B39A2.9040807@netbsd.org> <20151122112553.GA20758@roeckx.be> <5651B5BF.4050102@openssl.org> Message-ID: >> I'd like to propose the attached patch to 1.0.2d which avoids problems >> with strict ISO conforming compiler/options, which do not define 'sun' only >> '__sun' as usual... such as gcc/clang -std=c99 >> >> This affects the build itself, but also any user of openssl/opensslconf.h > > I've commited only the part that applied to the master branch, but > fixed that in all the branches. Please let me know if you need > other changes in the stable branches. There is partial contradiction here. It's argued in terms of contemporary compilers, while the code fragments in question, mostly those in e_os.h target specific *legacy* platform which is unlikely to have contemporary compiler. So that attempt to harmonize with recent compiler one breaks things for old compiler. One can argue that it's probably broken anyway, but it doesn't really make harmonization more right, does it? If platform is broken, then support should be disclaimed and correct approach would be to *remove* code. If support is not disclaimed then correct approach would be to look at target system, not what gcc/clang do on Linux. BTW, support for platform in question *is* disclaimed in master, so that in master code should be removed. Even that sys/filio.h thing, because default alternative works fine on Solaris. Side note about "#if define (sun) /* Newer Sparc's */" "sun" denotes OS vendor, not processor. So that it would be more appropriate to switch to sparc || __sparc__. From rt at openssl.org Sun Nov 22 13:08:55 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Sun, 22 Nov 2015 13:08:55 +0000 Subject: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options In-Reply-To: <5651BE66.1050700@openssl.org> References: <564B39A2.9040807@netbsd.org> <20151122112553.GA20758@roeckx.be> <5651B5BF.4050102@openssl.org> <5651BE66.1050700@openssl.org> Message-ID: >>> I'd like to propose the attached patch to 1.0.2d which avoids problems >>> with strict ISO conforming compiler/options, which do not define 'sun' only >>> '__sun' as usual... such as gcc/clang -std=c99 >>> >>> This affects the build itself, but also any user of openssl/opensslconf.h >> >> I've commited only the part that applied to the master branch, but >> fixed that in all the branches. Please let me know if you need >> other changes in the stable branches. > > ... If support [for SunOS 4] is not > disclaimed then correct approach would be to look at target system, not > what gcc/clang do on Linux. In other words I argue in favour of reverting suggested change in 1.0.1/2. Because I can't find evidence that __sun is defined on said platform. From rt at openssl.org Sun Nov 22 13:23:21 2015 From: rt at openssl.org (Richard PALO via RT) Date: Sun, 22 Nov 2015 13:23:21 +0000 Subject: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options In-Reply-To: <5651C1B6.4010805@netbsd.org> References: <564B39A2.9040807@netbsd.org> <20151122112553.GA20758@roeckx.be> <5651B5BF.4050102@openssl.org> <5651BE66.1050700@openssl.org> <5651C1B6.4010805@netbsd.org> Message-ID: Le 22/11/15 14:08, Andy Polyakov via RT a ?crit : >>>> I'd like to propose the attached patch to 1.0.2d which avoids problems >>>> with strict ISO conforming compiler/options, which do not define 'sun' only >>>> '__sun' as usual... such as gcc/clang -std=c99 >>>> >>>> This affects the build itself, but also any user of openssl/opensslconf.h >>> >>> I've commited only the part that applied to the master branch, but >>> fixed that in all the branches. Please let me know if you need >>> other changes in the stable branches. >> >> ... If support [for SunOS 4] is not >> disclaimed then correct approach would be to look at target system, not >> what gcc/clang do on Linux. > > In other words I argue in favour of reverting suggested change in > 1.0.1/2. Because I can't find evidence that __sun is defined on said > platform. > > > > FWIW, the generally accepted and documented platform tests include: > #ifdef __sun > /* this is SunOS */ > #endif > > #if defined(__sun) && defined(__SVR4) > /* this, in particular, is Solaris */ > #endif Naturally you can then add in hw architecture checks... -- Richard PALO From rt at openssl.org Sun Nov 22 14:12:45 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Sun, 22 Nov 2015 14:12:45 +0000 Subject: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options In-Reply-To: <5651CD5B.2050909@openssl.org> References: <564B39A2.9040807@netbsd.org> <20151122112553.GA20758@roeckx.be> <5651BE66.1050700@openssl.org> <5651C1B6.4010805@netbsd.org> <5651CD5B.2050909@openssl.org> Message-ID: >> In other words I argue in favour of reverting suggested change in >> 1.0.1/2. Because I can't find evidence that __sun is defined on said >> platform. >> >> >> >> > FWIW, the generally accepted and documented platform tests include: >> #ifdef __sun >> /* this is SunOS */ >> #endif I understand and appreciate this. But the point is that original conditions are supposed to work on platform that predates the moment the referred way became generally accepted. Once again, it either has to work with old compiler, or support for old compiler has to be disclaimed and code removed. Consider this. Do all SunOS 4 compilers define __sun? No. Do all of them define sun? Yes, they have to, because system headers depend on it. In worst case it probably should be sun || __sun, but sun alone is sufficient. For SunOS 4 that is. From rt at openssl.org Sun Nov 22 14:42:00 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Sun, 22 Nov 2015 14:42:00 +0000 Subject: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options In-Reply-To: <5651D438.2070202@openssl.org> References: <564B39A2.9040807@netbsd.org> <20151122112553.GA20758@roeckx.be> <5651BE66.1050700@openssl.org> <5651C1B6.4010805@netbsd.org> <5651D438.2070202@openssl.org> Message-ID: > FWIW, the generally accepted and documented platform tests include: >> #ifdef __sun >> /* this is SunOS */ >> #endif By the way, was it *actually* tested on SunOS 4? And if so, when and with which compiler? Is it possible that it simply was harmonized at some point with "we have double-underscore everywhere, don't we" rationale, without actual test on SunOS 4? And this way became kind of an urban legend? Well, I'm not actually asserting that I myself have possibility to test something on SunOS 4 now, but I have copy of system headers and see what did gcc 2.95 define... From rt at openssl.org Sun Nov 22 15:29:29 2015 From: rt at openssl.org (Richard PALO via RT) Date: Sun, 22 Nov 2015 15:29:29 +0000 Subject: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options In-Reply-To: <5651DF4B.50601@netbsd.org> References: <564B39A2.9040807@netbsd.org> <20151122112553.GA20758@roeckx.be> <5651C1B6.4010805@netbsd.org> <5651D438.2070202@openssl.org> <5651DF4B.50601@netbsd.org> Message-ID: Le 22/11/15 15:42, Andy Polyakov via RT a ?crit : >> FWIW, the generally accepted and documented platform tests include: >>> #ifdef __sun >>> /* this is SunOS */ >>> #endif > > By the way, was it *actually* tested on SunOS 4? And if so, when and > with which compiler? Is it possible that it simply was harmonized at > some point with "we have double-underscore everywhere, don't we" > rationale, without actual test on SunOS 4? And this way became kind of > an urban legend? Well, I'm not actually asserting that I myself have > possibility to test something on SunOS 4 now, but I have copy of system > headers and see what did gcc 2.95 define... > > > > Well, I admit I only checked back to gcc3... I did notice the following though: https://sourceforge.net/p/predef/wiki/OperatingSystems/ > #if defined(sun) || defined(__sun) > # if defined(__SVR4) || defined(__svr4__) > /* Solaris */ > # else > /* SunOS */ > # endif > #endif that is, if supporting that far back is indeed a goal, then *both* should be checked. Naturally that should be acceptable to most anybody concerned. cheers -- Richard PALO From rt at openssl.org Sun Nov 22 15:43:40 2015 From: rt at openssl.org (Pascal Cuoq via RT) Date: Sun, 22 Nov 2015 15:43:40 +0000 Subject: [openssl-dev] [openssl.org #4151] [PATCH] Function pop_info in crypto/mem_dbg.c returns a dangling pointer In-Reply-To: References: Message-ID: In crypto/mem_dbg.c, the type of static function pop_info() is to return an APP_INFO*. This pointer can be a dangling pointer, as can be seen in the following link as long as one assumes that line 382 is reachable (it is). https://github.com/openssl/openssl/blob/90945fa31a42dcf3beb90540c618e4d627c595ea/crypto/mem_dbg.c#L382-L386 Returning a dangling pointer from a function is not terribly good style. Using dangling pointers for anything is technically undefined behavior, so there is nothing in theory that a caller can do with the function's result that will not be illegal when a dangling pointer is returned. (It is well-known that dereferencing dangling pointers is undefined behavior, but examples at http://blog.regehr.org/archives/767#comment-4717 and at http://trust-in-soft.com/dangling-pointer-indeterminate/ show that the behavior of a program the *only* fault of which is to compare a dangling pointer to something else can be surprising too). The function pop_info() being static, no-one may use it outside mem_dbg.c and the callers inside mem_dbg.c do not dereference the returned pointer. They do use it in a comparison though, which should ideally be avoided because of the examples above. The attached patch does three small things: - change the type of the function to return an int: 1 if the pointer ret was non-null before being possibly freed, 0 otherwise, and adjust the two call sites correspondingly; - add a one-line comment describing the behavior of the function; - rename the local variable ret, the name of which no longer makes sense, into "current". None of these three things should change the behavior in practice of OpenSSL. As compiled with current C compilers, the tests "pop_info() != NULL" evaluated to 1 when a dangling pointer was returned. These tests were replaced with "pop_info()" which now evaluates to 1 under the circumstances in which a dangling pointer was returned. -------------- next part -------------- A non-text attachment was scrubbed... Name: pop_info.patch Type: application/octet-stream Size: 2548 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sun Nov 22 15:45:12 2015 From: rt at openssl.org (Richard PALO via RT) Date: Sun, 22 Nov 2015 15:45:12 +0000 Subject: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options In-Reply-To: <5651E2FB.8090904@free.fr> References: <564B39A2.9040807@netbsd.org> <20151122112553.GA20758@roeckx.be> <5651C1B6.4010805@netbsd.org> <5651D438.2070202@openssl.org> <5651DF4B.50601@netbsd.org> <5651E2FB.8090904@free.fr> Message-ID: Le 22/11/15 16:29, Richard PALO a ?crit : > Le 22/11/15 15:42, Andy Polyakov via RT a ?crit : >>> FWIW, the generally accepted and documented platform tests include: >>>> #ifdef __sun >>>> /* this is SunOS */ >>>> #endif >> >> By the way, was it *actually* tested on SunOS 4? And if so, when and >> with which compiler? Is it possible that it simply was harmonized at >> some point with "we have double-underscore everywhere, don't we" >> rationale, without actual test on SunOS 4? And this way became kind of >> an urban legend? Well, I'm not actually asserting that I myself have >> possibility to test something on SunOS 4 now, but I have copy of system >> headers and see what did gcc 2.95 define... >> >> >> >> > Well, I admit I only checked back to gcc3... I did notice the following though: > https://sourceforge.net/p/predef/wiki/OperatingSystems/ >> #if defined(sun) || defined(__sun) >> # if defined(__SVR4) || defined(__svr4__) >> /* Solaris */ >> # else >> /* SunOS */ >> # endif >> #endif > > that is, if supporting that far back is indeed a goal, then *both* should be checked. Naturally that should be acceptable to most anybody concerned. > > cheers > BTW from what I can see, 'sun' being not defined with '-ansi' was already documented in https://gcc.gnu.org/onlinedocs/gcc-2.95.3/cpp_1.html -- Richard PALO From rt at openssl.org Sun Nov 22 16:26:51 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Sun, 22 Nov 2015 16:26:51 +0000 Subject: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options In-Reply-To: <5651ECCA.4050101@openssl.org> References: <564B39A2.9040807@netbsd.org> <20151122112553.GA20758@roeckx.be> <5651D438.2070202@openssl.org> <5651DF4B.50601@netbsd.org> <5651ECCA.4050101@openssl.org> Message-ID: >>> FWIW, the generally accepted and documented platform tests include: >>>> #ifdef __sun >>>> /* this is SunOS */ >>>> #endif >> >> By the way, was it *actually* tested on SunOS 4? And if so, when and >> with which compiler? Is it possible that it simply was harmonized at >> some point with "we have double-underscore everywhere, don't we" >> rationale, without actual test on SunOS 4? And this way became kind of >> an urban legend? Well, I'm not actually asserting that I myself have >> possibility to test something on SunOS 4 now, but I have copy of system >> headers and see what did gcc 2.95 define... >> >> >> >> > Well, I admit I only checked back to gcc3... I did notice the following though: > https://sourceforge.net/p/predef/wiki/OperatingSystems/ >> #if defined(sun) || defined(__sun) >> # if defined(__SVR4) || defined(__svr4__) >> /* Solaris */ >> # else >> /* SunOS */ >> # endif >> #endif > > that is, if supporting that far back is indeed a goal, Irregardless whether or not goal is formulated like *this*, it's definitely can be formulated at least as "keep even legacy platforms in mind". I mean it's more about discipline. > then *both* should be checked. Naturally that should be acceptable to most anybody concerned. If you want distinguish Solaris, yes. But if you want to distinguish specifically SunOS 4, 'sun' is guaranteed to do the job. Because compiler that targets SunOS 4 *has to* have it. Either way, we seem to agree that *replacing* sun with __sun is not right thing to do in SunOS 4 context. One can argue for sun || __sun, or one can argue in favour of reverting. My vote goes for latter, because original conditions [in e_os.h] do work adequately. Well, one can argue that it works *incidentally*, but in such situation I usually reason that released software has certain "mass" and one should approach it more pragmatically. At the very least one shouldn't consider "strict ISO conformity" in broadest sense, but even answer question how does it affect platforms in specific supported configurations reflected in Configure. As for reference to 'sun' not being defined with -ansi already in 2.95. At the same time it also says that it's basically counterproductive, because [once again] system headers require it. One should also keep in mind that standard compliance is never perfect, especially on older systems, and you're driven to make trade-offs. Like the one in question. From inge at syssurge.com Sun Nov 22 19:42:36 2015 From: inge at syssurge.com (Inge Henriksen) Date: Sun, 22 Nov 2015 19:42:36 +0000 Subject: [openssl-dev] Building Open Message-ID: Hi. I believe that I've found some issues while to build OpenSSL v1.0.2b for 64-bit Intel compatible CPUs on Windows 10 using Visual Studio 2015. There is a bug in the ms\do_win64a.bat OpenSSL batch file that causes some of the libraries to be built as 32-bit, to fix this you can do the following; open and edit ms\do_win64a.bat in notepad by typing the following in the command shell: notepad ms\do_win64a.bat Now you must make sure that the ms\do_win64a.bat contents matches the following and overwrite the file after you have made it so: -------- perl util\mkfiles.pl >MINFO cmd /c "nasm -f win64 -v" >NUL 2>&1 if %errorlevel% neq 0 goto ml64 perl ms\uplink-x86_64.pl nasm > ms\uptable.asm nasm -f win64 -o ms\uptable.obj ms\uptable.asm goto proceed :ml64 perl ms\uplink-x86_64.pl masm > ms\uptable.asm ml64 -c -Foms\uptable.obj ms\uptable.asm :proceed perl util\mk1mf.pl VC-WIN64A >ms\nt.mak perl util\mk1mf.pl dll VC-WIN64A >ms\ntdll.mak perl util\mkdef.pl 64 libeay > ms\libeay32.def perl util\mkdef.pl 64 ssleay > ms\ssleay32.def -------- With that everything builds and unit tests ran, but the output binaries are still named "32" even though they are 64-bit which is confusing. Read more in my blog here: https://ingehenriksen.wordpress.com/2015/11/22/building-openssl-1-0-2d-64-bit-on-windows-with-visual-studio-2015/ Thank you. Kind regards, Inge. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sun Nov 22 20:46:31 2015 From: rt at openssl.org (Tianjie Mao via RT) Date: Sun, 22 Nov 2015 20:46:31 +0000 Subject: [openssl-dev] [openssl.org #4152] [PATCH] SRP code clean-up s_client and s_server In-Reply-To: References: Message-ID: Hello, SRP is a secure password authentication / key exchange protocol. When the original SRP patches for OpenSSL were created by the EdelKey project back in 2000s, the highest version of TLS standard remained 1.0. Some code, however, if left unchanged, would by default restrict communications to TLSv1 while refusing to negotiate later versions of security. It would also interfere with command line switches such as -tls1_1 and -tls1_2. These lines were from old patches and need to be cleaned up. The following diff was made against OpenSSL_1_0_2-stable. --- apps/s_server.c.orig 2015-11-23 03:36:01.445020272 +0800 +++ apps/s_server.c 2015-11-23 03:41:29.579617191 +0800 @@ -1424,12 +1424,10 @@ if (--argc < 1) goto bad; srp_verifier_file = *(++argv); - meth = TLSv1_server_method(); } else if (strcmp(*argv, "-srpuserseed") == 0) { if (--argc < 1) goto bad; srpuserseed = *(++argv); - meth = TLSv1_server_method(); } #endif else if (strcmp(*argv, "-rev") == 0) { --- apps/s_client.c.orig 2015-11-23 03:36:01.441020388 +0800 +++ apps/s_client.c 2015-11-23 04:01:58.272199415 +0800 @@ -922,25 +922,20 @@ if (--argc < 1) goto bad; srp_arg.srplogin = *(++argv); - meth = TLSv1_client_method(); } else if (strcmp(*argv, "-srppass") == 0) { if (--argc < 1) goto bad; srppass = *(++argv); - meth = TLSv1_client_method(); } else if (strcmp(*argv, "-srp_strength") == 0) { if (--argc < 1) goto bad; srp_arg.strength = atoi(*(++argv)); BIO_printf(bio_err, "SRP minimal length for N is %d\n", srp_arg.strength); - meth = TLSv1_client_method(); } else if (strcmp(*argv, "-srp_lateuser") == 0) { srp_lateuser = 1; - meth = TLSv1_client_method(); } else if (strcmp(*argv, "-srp_moregroups") == 0) { srp_arg.amp = 1; - meth = TLSv1_client_method(); } #endif #ifndef OPENSSL_NO_SSL2 @@ -1101,7 +1096,6 @@ if (--argc < 1) goto bad; servername = *(++argv); - /* meth=TLSv1_client_method(); */ } #endif #ifndef OPENSSL_NO_JPAKE _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From dragon at dancingdragon.be Sun Nov 22 22:16:45 2015 From: dragon at dancingdragon.be (Joey Yandle) Date: Sun, 22 Nov 2015 14:16:45 -0800 Subject: [openssl-dev] Building Open In-Reply-To: References: Message-ID: <56523ECD.9090505@dancingdragon.be> > I believe that I've found some issues while to build OpenSSL v1.0.2b for > 64-bit Intel compatible CPUs on Windows 10 using Visual Studio 2015. It appears that you skipped a step that was listed in INSTALL.W64, specifically perl Configure VC-WIN64A 1.0.2* builds normally for me on amd64 if that step is not skipped. You are correct that 64-bit binaries are improperly labeled with '32'. I do plan on fixing that at some point, though in the meantime it makes my life easier (my scripts can always assume the same library name). cheers, Joey From rt at openssl.org Mon Nov 23 00:07:03 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 23 Nov 2015 00:07:03 +0000 Subject: [openssl-dev] [openssl.org #4151] [PATCH] Function pop_info in crypto/mem_dbg.c returns a dangling pointer In-Reply-To: References: Message-ID: We have another internal cleanup in-progress that will fix this in a different way. From for-gmane at mutluit.com Mon Nov 23 05:32:43 2015 From: for-gmane at mutluit.com (U.Mutlu) Date: Mon, 23 Nov 2015 06:32:43 +0100 Subject: [openssl-dev] [libcrypto EVP] valgrind reports many memory leaks in wiki-example Message-ID: Hi, running the following example from the openssl wiki site under valgrind gives many memory-leaks in the underlying library functions: https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption $ gcc -Wall -O2 test_encdec.c -lcrypto $ valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --track-origins=yes -v ./a.out &>valgrind-output.txt Attached is the valgrind-output. It says: 34 not-freed blocks Are these maybe false-positives? The leak summary in the output says this: ==9895== LEAK SUMMARY: ==9895== definitely lost: 0 bytes in 0 blocks ==9895== indirectly lost: 0 bytes in 0 blocks ==9895== possibly lost: 0 bytes in 0 blocks ==9895== still reachable: 2,632 bytes in 34 blocks ==9895== suppressed: 0 bytes in 0 blocks OS: Debian 8 amd64, using libs from the Debian repo: libcrypto: 5.6.1-6+deb8u1 openssl: 1.0.1k-3+deb8u1 -- U.Mutlu -------------- next part -------------- A non-text attachment was scrubbed... Name: valgrind-output.txt.gz Type: application/gzip Size: 3231 bytes Desc: not available URL: From for-gmane at mutluit.com Mon Nov 23 05:43:59 2015 From: for-gmane at mutluit.com (U.Mutlu) Date: Mon, 23 Nov 2015 06:43:59 +0100 Subject: [openssl-dev] [libcrypto EVP] valgrind reports many memory leaks in wiki-example In-Reply-To: References: Message-ID: U.Mutlu wrote on 11/23/2015 06:32 AM: > Hi, > running the following example from the openssl wiki site under valgrind > gives many memory-leaks in the underlying library functions: > https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption > > $ gcc -Wall -O2 test_encdec.c -lcrypto Typo above: I rather had used the -ggdb switch: $ gcc -Wall -ggdb test_encdec.c -lcrypto > $ valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all > --track-origins=yes -v ./a.out &>valgrind-output.txt > > Attached is the valgrind-output. It says: > 34 not-freed blocks > > Are these maybe false-positives? The leak summary in the output says this: > ==9895== LEAK SUMMARY: > ==9895== definitely lost: 0 bytes in 0 blocks > ==9895== indirectly lost: 0 bytes in 0 blocks > ==9895== possibly lost: 0 bytes in 0 blocks > ==9895== still reachable: 2,632 bytes in 34 blocks > ==9895== suppressed: 0 bytes in 0 blocks > > OS: Debian 8 amd64, using libs from the Debian repo: > libcrypto: 5.6.1-6+deb8u1 > openssl: 1.0.1k-3+deb8u1 -- U.Mutlu From rt at openssl.org Mon Nov 23 07:16:22 2015 From: rt at openssl.org (Richard PALO via RT) Date: Mon, 23 Nov 2015 07:16:22 +0000 Subject: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options In-Reply-To: <5652BD30.3060601@netbsd.org> References: <564B39A2.9040807@netbsd.org> <20151122112553.GA20758@roeckx.be> <5651DF4B.50601@netbsd.org> <5651ECCA.4050101@openssl.org> <5652BD30.3060601@netbsd.org> Message-ID: Le 22/11/15 17:26, Andy Polyakov via RT a ?crit : > > If you want distinguish Solaris, yes. But if you want to distinguish > specifically SunOS 4, 'sun' is guaranteed to do the job. Because > compiler that targets SunOS 4 *has to* have it. Either way, we seem to > agree that *replacing* sun with __sun is not right thing to do in SunOS > 4 context. One can argue for sun || __sun, or one can argue in favour of > reverting. My vote goes for latter, because original conditions [in > e_os.h] do work adequately. Well, one can argue that it works > *incidentally*, but in such situation I usually reason that released > software has certain "mass" and one should approach it more > pragmatically. At the very least one shouldn't consider "strict ISO > conformity" in broadest sense, but even answer question how does it > affect platforms in specific supported configurations reflected in > Configure. > Not really looking to argue, but I don't believe this to be entirely true. That is, gcc 2.95 is certainly not the only compiler available on SunOS 4... even today SunOS can install packages from, for a perfect example, pkgsrc which provides gcc{2..5}. Any gcc3 or higher *always* generates '__sun'. So does clang. Sun/Solaris Studio do so as well. Compilers for the obsolete BSD-based SunOS also defined __sun (according to http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system) On the other hand, I believe openssl 1.0 was released somewhere around 2010, ten years after (love the group:-) the 2.95 release of gcc. So I wonder which compiler is really used in practice? > As for reference to 'sun' not being defined with -ansi already in 2.95. > At the same time it also says that it's basically counterproductive, > because [once again] system headers require it. One should also keep in > mind that standard compliance is never perfect, especially on older > systems, and you're driven to make trade-offs. Like the one in question. > > Well, I can't speak for the author of the above note on the gcc site, but to extract a recent quote from a NetBSD and pkgsrc developer: "Programs should be written to standards, not gcc extensions." In the meanwhile there is -std=c99 and more recently -std=c11 that have been published with the similar strict requirements. Finally, I would be happy add back the check for 'sun' as well as '__sun' if deemed necessary. cheers, -- Richard PALO From rt at openssl.org Mon Nov 23 07:49:26 2015 From: rt at openssl.org (Quanah Gibson-Mount via RT) Date: Mon, 23 Nov 2015 07:49:26 +0000 Subject: [openssl-dev] [openssl.org #4153] [PATCH] Fix grammar errors in s_client.c In-Reply-To: <1D544093B5E8AD8F1DF5AD18@[192.168.1.9]> References: <1D544093B5E8AD8F1DF5AD18@[192.168.1.9]> Message-ID: This patch fixes small grammar errors in s_client.c. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Nov 23 07:49:26 2015 From: rt at openssl.org (Kirill Marinushkin via RT) Date: Mon, 23 Nov 2015 07:49:26 +0000 Subject: [openssl-dev] [openssl.org #4154] [PATCH] BIO mem read optimization In-Reply-To: References: Message-ID: 2 BIO_s_mem issues solved: - BIO mem read without reallocation - reading by parts becomes faster; - flag added to rewind read write BIO mem on reset. OpenSSL self-test report: OpenSSL version: 1.1.0-dev Last change: State machine rewrite. The state machine code has been ... Options: -march=pentium -Wa,--noexecstack no-deprecated no-ec_nistp_64_gcc_128 no-gmp no-jpake no-md2 no-rc5 no-sctp no-shared no-ssl-trace no-store no-unit-test no-zlib no-zlib-dynamic static-engine OS (uname): Linux kirill-Lenovo-B570e 3.13.0-68-generic #111-Ubuntu SMP Fri Nov 6 18:18:09 UTC 2015 i686 i686 i686 GNU/Linux OS (config): i686-whatever-linux2 Target (default): linux-elf Target: linux-elf Compiler: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.8/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.4-2ubuntu1~14.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --enable-multiarch --disable-werror --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04) Test passed. -- Best Regards, Kirill Marinushkin -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl_bio_s_mem.patch Type: text/x-patch Size: 10002 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Nov 23 09:38:29 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 23 Nov 2015 09:38:29 +0000 Subject: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options In-Reply-To: <5652DE92.5050600@openssl.org> References: <564B39A2.9040807@netbsd.org> <20151122112553.GA20758@roeckx.be> <5651ECCA.4050101@openssl.org> <5652BD30.3060601@netbsd.org> <5652DE92.5050600@openssl.org> Message-ID: >> If you want distinguish Solaris, yes. But if you want to distinguish >> specifically SunOS 4, 'sun' is guaranteed to do the job. Because >> compiler that targets SunOS 4 *has to* have it. Either way, we seem to >> agree that *replacing* sun with __sun is not right thing to do in SunOS >> 4 context. One can argue for sun || __sun, or one can argue in favour of >> reverting. My vote goes for latter, because original conditions [in >> e_os.h] do work adequately. Well, one can argue that it works >> *incidentally*, but in such situation I usually reason that released >> software has certain "mass" and one should approach it more >> pragmatically. At the very least one shouldn't consider "strict ISO >> conformity" in broadest sense, but even answer question how does it >> affect platforms in specific supported configurations reflected in >> Configure. >> > > Not really looking to argue, but I don't believe this to be entirely > true. That is, gcc 2.95 is certainly not the only compiler available > on SunOS 4... even today SunOS can install packages from, for a perfect > example, pkgsrc which provides gcc{2..5}. I didn't say that gcc 2.95 is the only one available. But to make the [above] point any that underpins it is sufficient. So it happens to be 2.95. > Any gcc3 or higher *always* generates '__sun'. So does clang. > Sun/Solaris Studio do so as well. Compilers for the obsolete BSD-based SunOS also defined __sun (according to http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system) > > On the other hand, I believe openssl 1.0 was released somewhere around 2010, > ten years after (love the group:-) the 2.95 release of gcc. So I wonder which > compiler is really used in practice? Once again, question is not what contemporary compilers do, but if there a way that is guaranteed to work. Because if there is, we have freedom not to think which compiler is actually used in any particular case, as well as give more swing room to end user/developer. If you wish one can say that objective is to make it work in maximum amount of situations, *and* not necessarily limited to ISO pure-room conditions. >> As for reference to 'sun' not being defined with -ansi already in 2.95. >> At the same time it also says that it's basically counterproductive, >> because [once again] system headers require it. One should also keep in >> mind that standard compliance is never perfect, especially on older >> systems, and you're driven to make trade-offs. Like the one in question. >> >> > > Well, I can't speak for the author of the above note on the gcc site, > but to extract a recent quote from a NetBSD and pkgsrc developer: > "Programs should be written to standards, not gcc extensions." Sure, but world is simply not perfect. I'm not saying that we shouldn't try to improve it, we totally should. It's only that sometimes we can't be as categorical, and I don't think we should feel bad about making some compromises, most notably when it comes to legacy systems... From rt at openssl.org Mon Nov 23 13:33:23 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 23 Nov 2015 13:33:23 +0000 Subject: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options In-Reply-To: <5653159F.5000403@openssl.org> References: <564B39A2.9040807@netbsd.org> <20151122112553.GA20758@roeckx.be> <5651DF4B.50601@netbsd.org> <5651ECCA.4050101@openssl.org> <5653159F.5000403@openssl.org> Message-ID: > ... Either way, we seem to > agree that *replacing* sun with __sun is not right thing to do in SunOS > 4 context. One can argue for sun || __sun, or one can argue in favour of > reverting. My vote goes for latter, because original conditions [in > e_os.h] do work adequately. After closer look I have to withdraw my preference for just reverting. Because there is one case that is not appropriate for *Solaris*. Initially I noted that Solaris sys/ioctl.h includes sys/filio.h, but I failed to notice and latter's inclusion is conditional and condition is not met when OpenSSL compiles with defaults flags. As compiler targeting Solaris doesn't *have to* define 'sun' for system headers to work, one has to reserve for possibility that it's absent. From tshort at akamai.com Mon Nov 23 16:05:12 2015 From: tshort at akamai.com (Short, Todd) Date: Mon, 23 Nov 2015 16:05:12 +0000 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <201511210210.tAL2AvJi030500@d23av02.au.ibm.com> References: <3CB9005A-76B1-4F42-BA72-DE46AB82C27D@akamai.com> <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <201511210210.tAL2AvJi030500@d23av02.au.ibm.com> Message-ID: I suspect that most ?users? of OpenSSL are doing it indirectly through other applications that use TLS (or crypto) functionality. Example: the Cisco AnyConnect client is reportedly one of the most installed pieces of software regardless of platform; it uses OpenSSL for TLS. Taking those indirect users into account, they don?t care about the research or advanced uses of OpenSSL; they just want to connect securely to their corporate network. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Nov 20, 2015, at 9:09 PM, Peter Waltenberg > wrote: Quite reasonable except. I'm not sure you have majority and minority the right way around. My guess would be that the majority of OpenSSL users are libcrypto. consumers rather than SSL/TLS consumers. A point several of us have been trying to get through for some time. Peter -----"openssl-dev" > wrote: ----- To: "openssl-dev at openssl.org" > From: "Short, Todd" Sent by: "openssl-dev" Date: 11/21/2015 08:28AM Cc: "openssl-users at openssl.org" > Subject: Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback While I am all for simplicity, I also think that removing functionality is a ?bad idea?. To reduce the support burden, deprecate the ciphers: 1. Under support, indicate that these ciphers will no longer receive fixes. 2. Remove any assembly implementations 3. Disable them by default. I suggest following the 80/20 rule (sometimes the 95/5 rule): Those ?who care? (the minority) about the ciphers can re-enable them and rebuild the library. Those ?who don?t care? (the majority) about the ciphers, should get the functionality that most people care about, basically SSL/TLS connectivity. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL > wrote: On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk" on behalf of bkaduk at akamai.com> wrote: On 11/18/2015 07:05 AM, Hubert Kario wrote: So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to support both relatively modern TLS with user certificates, preferably the newest cryptosystems and hashes as well as the oldest ones that were standardised and used. That means that old algorithms MUST remain in OpenSSL as supported functionality. It may require linking to a specific library to make the EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed from it completely, definitely not before at least 50 years _after_ they became obsolete and broken. There seems to be a logical leap between these two paragraphs. Why is it necessary that OpenSSL be the only cryptographic library used by CAdES-A/etc. implementations? Because it used to be the only real game in town, and *people learned to rely upon it*. Is it in fact even necessary that only a single version of a single cryptographic library be used for such software? No, of course not. But after letting people depend on this ?single cryptographic library? for many years, telling them ?too bad? isn?t very nice. While OpenSSL may try to be a general-purpose crypto library, when a software has stringent or unusual crypto requirements, it seems reasonable that such a software may need to involve unusual implementations. The requirements did not change. What changed was the maintainers expressing their desire to stop supporting some of them. I do not believe that OpenSSL has promised anywhere that it will support this sort of use case. Implicitly, by providing that kind of service for so long. And explicitly, as pointed out by Hubert: From the main web page of project: The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, *full-featured*, and Open Source toolkit implementing the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols as well as a full-strength *general purpose* *cryptography library* . _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico at cryptonector.com Mon Nov 23 05:41:44 2015 From: nico at cryptonector.com (Nico Williams) Date: Sun, 22 Nov 2015 23:41:44 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151123015347.GJ18315@mournblade.imrryr.org> References: <20151123015347.GJ18315@mournblade.imrryr.org> Message-ID: <20151123054139.GB11308@localhost> [Viktor asked me for my advice on this issue and bounced me the post that I'm following up to. -Nico] The summary of what I've to say is that making libcrypto and libssl need -lpthread is something that does require discussion, as it will have detrimental effects on some users. Personally, I think that those detrimental effects are a good thing (see below), but nonetheless I encourage you to discuss whether this is actually what OpenSSL should do. In particular, it may be possible to avoid -lpthread on some systems and still get a subset of lipthread functionality from libc or the compiler (e.g., thread-locals), and that may be worth doing. On Mon, Nov 23, 2015 at 01:53:47AM +0000, Viktor Dukhovni wrote: > As a side-effect of the MacOS/X MR I've become aware that the async > code in its current state links master with "-lphtread", and defines > macros that enable multi-theaded (as opposed to merely thread-safe) > compilation into OpenSSL. > > commit 757d14905e3877abaa9f258f3dd0694ae3c7c270 > Author: Matt Caswell > Date: Thu Nov 19 14:55:09 2015 +0000 > > Add pthread support > > The forthcoming async code needs to use pthread thread local variables. This > updates the various Configurations to add the necessary flags. In many cases > this is an educated guess as I don't have access to most of these > environments! There is likely to be some tweaking needed. > > Reviewed-by: Kurt Roeckx > > This is quite possibly not be the right thing to do, and deserves > some attention from the team. We might even seek outside som > outside advice from folks well versed in platform-specific library > engineering (Christos Zoulas from NetBSD, Nico Williams formerly > from Sun, ...). > > My concern is that introducing -lpthread automatically converts > single-threaded applications that link with OpenSSL into threaded > applications (with a single thread). This may well have undesirable > consequences. Some background may be needed. When threading was introduced in the 90s, and in some cases still to this day, generally the end result was that the system had to support a number "process models", with potential transitions from one to another at run-time: - single-threaded, dynamically linked - single-threaded, statically linked - multi-threaded, dynamically linked - multi-threaded, statically linked - multi-threaded, mixed linkage The statically-linked models can become mixed-linkage models via dlopen(). The single-threaded model can become a threaded model via dlopen() of an object linked with -lpthread, or by dlopen()ing libpthread itself. Solaris 9 and under used to have a veritable rats nest of code to deal with the process model transitions from single-threaded to multi-threaded. Solaris 10 unified these and moved libpthread and libdl into libc [with filters left behind for backwards compatibility]. Thus, on Solaris 10 and up, and Illumos, OpenSSL using -lpthread or not makes no difference. I'm quite fond of the approach taken by Solaris 10 and up (and thus also Illumos): there is but one process model, and it is threaded, with pthreads in libc. But that need not be the way it works everywhere. Some systems may still support multiple process models. For a library like OpenSSL making use of -lpthread does mean dictating to users that they may only use a threaded process model. OTOH, not using -lpthread allows the user to choose a process model unconstrained by such a library. Until now OpenSSL has avoided forcing the user to choose any particular process model. Now with this commit OpenSSL is now taking the reverse stance. This seems like a very significant change that should at least be noted prominently in the release notes, but it should also be disucssed, indeed. Personally, I believe this change is a good thing, as OpenSSL really ought to either automatically initialize its "lock callbacks" or do away with them completely (leaving backwards compatibility stubs) and use the OS' locking facility by default / only. Automatic lock callback initialization without forcing the use of -lpthread and still allowing static linking would be tricky indeed (for example: OpenSSL couldn't use weak symbols to detect when -lpthread gets brought in). Still, if -lpthread avoidance were still desired, you'd have to find an alternative to pthread_key_create(), pthread_getspecific(), and friends. For thread-specifics the obvious answer is to use C compiler thread-local variable support. This might or might not be available; this would have to be determined at build configuration time. Still, if where the compiler supports thread-locals, OpenSSL could avoid -lpthread. For pthread mutex functions (for lock callbacks) and, perhaps, pthread_once() (for automatic initialization of lock callbacks, perhaps), it's very difficult to create alternatives to -lpthread, but it can conceivably be done within a library like OpenSSL. I don't think it's worth doing though! Instead I think it's best to just use -lpthread and let the OS and its libc and libpthread take care of any desirable optimizations in single-threaded cases, as well as any automatic transitions to non-optimized implementations upon creation of the first additional thread. The single-threaded and statically linked process model has a number of detrimental effects, and ISTM that by bending over backwards to avoid forcing the choice of process model, OpenSSL and similar allow users to believe in fairy tales. One detrimental effect has been OpenSSL's bloody lock callbacks, which in turn mean that it is impossible to use OpenSSL perfectky thread-safely from another library! Must every program use -lcrypto and -lpthread, and setup lock callbacks just in case some other library the program really does use calls dlopen()? Other detrimental effects of static linking include: - the flattened dependency topology forced by static linking (with attendant confusion in *-cofig(1) programs), with attendant accidental symbol interposition; - partial loss of ASLR protection (one random load address for the entire executable text and all its libraries, versus one for each object) - the need for complex single- to multi-threaded transition support code in various system libraries (mostly in libc). - slower load times. Yes, slower. A single statically-linked executable will load faster than the same program dynamically-linked. But a larger system than just one executable (e.g., the host OS, related applications, helper programs, ...) will load slower because multiple copies of common texts will not be shareable. If a major library like OpenSSL were to force operating systems to deal with the shortcommings of mixed process models and static linking, that would be a good thing. That's what OpenSSL would be doing by using -lpthread. > The C-library on many platforms is carefully designed to operate > efficiently and locklessly in single-threaded applications, and to > only switch to thread-aware implementations of functions when the > pthread library is loaded. I don't think the loss of the lockless optimizations should be of particular concern to OpenSSL: if that's a problem for a given OS, let its implementors deal with it. (They can do it, by, e.g., hot-swapping lock functions at pthread_create() call time rather than at the time that libpthread is loaded.) > In NetBSD, for example, the header file carefully > defines non-threaded (or rather lazily threaded only when pthread > is also loaded) versions of various pthread functions, see the > extract of pthread.h below my signature. It shouldn't be the loading of libpthread that causes transition to a threaded model (and, therefore, loss of single-threaded optimizations), but calling pthread_create(). If NetBSD really does the former, well, too bad: it really ought to be changed to do the latter. > Therefore, on any platform where the C-library is properly engineered > in this way (at least NetBSD and MacOS/X), we should not be > introducing -lpthread or definining "-D_REENTRANT", ... Nonetheless, this is good advice. If the necessary functionality from libpthread can be found in libc (or, in the case of thread-locals, in the compiler), then OpenSSL should avoid bringing in -lpthread. As long as they support seamless upgrade to threaded model via dlopen(), this is good advice. Of course, this does mean that OpenSSL needs more complexity in its configurator: to decide when to use -lpthread and when not to. > We are a thread-safe library, *not* a threaded library, and must > not introduce threading into threaded applications. That's a fairy tale. OpenSSL is only thread-safe when either a) used only in single-threaded processes that never transition to multi-threaded process models, or b) when the program initializes the OpenSSL lock callbacks before any libraries that need OpenSSL. Those two constraints are so difficult to meet that I don't think it's fair to call OpenSSL a thread-safe library at all. It's time to fix this. If OpenSSL will now require -lpthread, then it gets easier, certainly, so I'm not exactly against OpenSSL requiring -lpthread! ;) > We should think carefully about which platforms get async support > (perhaps one at time, and before it has been tested), and whether > "-pthread" is an acceptable penalty for any potential future > advantage of async support (none at present). > > Thoughts? Comments? See above. I'm not sure you'll be please with mine :) > -- > Viktor. > > [NetBSD header commentary extracts elided] Nico -- From nico at cryptonector.com Mon Nov 23 17:49:38 2015 From: nico at cryptonector.com (Nico Williams) Date: Mon, 23 Nov 2015 11:49:38 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151123015347.GJ18315@mournblade.imrryr.org> References: <20151123015347.GJ18315@mournblade.imrryr.org> Message-ID: <20151123174937.GA9363@localhost> [Resend, with slight edits.] [Viktor asked me for my advice on this issue and bounced me the post that I'm following up to. -Nico] The summary of what I've to say is that making libcrypto and libssl need -lpthread is something that does require discussion, as it will have detrimental effects on some users. Personally, I think that those detrimental effects are a good thing (see below), but nonetheless I encourage you to discuss whether this is actually what OpenSSL should do. In particular, it may be possible to avoid -lpthread on some systems and still get a subset of lipthread functionality from libc or the compiler (e.g., thread-locals), and that may be worth doing. On a slightly related note, I asked and Viktor tells me that fiber stacks are allocated with malloc(). I would prefer that they were allocated with mmap(), because then you get a guard page. A guard page would allow one to safely tune down fiber stack size to the whatever OpenSSL actually needs for a given use. Comments below. On Mon, Nov 23, 2015 at 01:53:47AM +0000, Viktor Dukhovni wrote: > As a side-effect of the MacOS/X MR I've become aware that the async > code in its current state links master with "-lphtread", and defines > macros that enable multi-theaded (as opposed to merely thread-safe) > compilation into OpenSSL. > > commit 757d14905e3877abaa9f258f3dd0694ae3c7c270 > Author: Matt Caswell > Date: Thu Nov 19 14:55:09 2015 +0000 > > Add pthread support > > The forthcoming async code needs to use pthread thread local variables. This > updates the various Configurations to add the necessary flags. In many cases > this is an educated guess as I don't have access to most of these > environments! There is likely to be some tweaking needed. > > Reviewed-by: Kurt Roeckx > > This is quite possibly not be the right thing to do, and deserves > some attention from the team. We might even seek outside some > outside advice from folks well versed in platform-specific library > engineering (Christos Zoulas from NetBSD, Nico Williams formerly > from Sun, ...). > > My concern is that introducing -lpthread automatically converts > single-threaded applications that link with OpenSSL into threaded > applications (with a single thread). This may well have undesirable > consequences. Some background may be needed. When threading was introduced in the 90s, and in some cases still to this day, generally the end result was that the system had to support a number "process models", with potential transitions from one to another at run-time: - single-threaded, dynamically linked - single-threaded, statically linked - multi-threaded, dynamically linked - multi-threaded, statically linked - multi-threaded, mixed linkage The statically-linked models can become mixed-linkage models via dlopen(). The single-threaded model can become a threaded model via dlopen() of an object linked with -lpthread, or by dlopen()ing libpthread itself. Solaris 9 and under used to have a veritable rats nest of code to deal with the process model transitions from single-threaded to multi-threaded. Solaris 10 unified these and moved libpthread and libdl into libc [with filters left behind for backwards compatibility]. Thus, on Solaris 10 and up, and Illumos, OpenSSL using -lpthread or not makes no difference. I'm quite fond of the approach taken by Solaris 10 and up (and thus also Illumos): there is but one process model, and it is threaded, with pthreads in libc. But that need not be the way it works everywhere. Some systems may still support multiple process models. For a library like OpenSSL making use of -lpthread does mean dictating to users that they may only use a threaded process model. OTOH, not using -lpthread allows the user to choose a process model unconstrained by such a library. Until now OpenSSL has avoided forcing the user to choose any particular process model. Now with this commit OpenSSL is now taking the reverse stance. This seems like a very significant change that should at least be noted prominently in the release notes, but it should also be discussed, indeed. Personally, I believe this change is a good thing, as OpenSSL really ought to either automatically initialize its "lock callbacks" or do away with them completely (leaving backwards compatibility stubs) and use the OS' locking facility by default / only. Automatic lock callback initialization without forcing the use of -lpthread and still allowing static linking would be tricky indeed (for example: OpenSSL couldn't use weak symbols to detect when -lpthread gets brought in). Still, if -lpthread avoidance were still desired, you'd have to find an alternative to pthread_key_create(), pthread_getspecific(), and friends. For thread-specifics the obvious answer is to use C compiler thread-local variable support. This might or might not be available; this would have to be determined at build configuration time. Still, if where the compiler supports thread-locals, OpenSSL could avoid -lpthread. For pthread mutex functions (for lock callbacks) and, perhaps, pthread_once() (for automatic initialization of lock callbacks, perhaps),... On some systems these functions will be in libc. For the rest it's very difficult to create alternatives to requiring -lpthread, though it can conceivably be done within a library like OpenSSL. I just don't think it's worth doing though! Instead I think it's best to just use -lpthread and let the OS and its libc and libpthread take care of any desirable optimizations in single-threaded cases, as well as any automatic transitions to non-optimized implementations upon creation of the first additional thread. The single-threaded and statically linked process model has a number of detrimental effects, and ISTM that by bending over backwards to avoid forcing the choice of process model, OpenSSL and similar allow users to believe in fairy tales. One detrimental effect has been OpenSSL's bloody lock callbacks, which in turn mean that it is impossible to use OpenSSL thread-safely from another library! Must every program use -lcrypto and -lpthread, and setup lock callbacks just in case some other library the program really does use calls dlopen()? Other detrimental effects of static linking include: - the flattened dependency topology forced by static linking (with attendant confusion in *-config(1) programs), with attendant accidental symbol interposition; - partial loss of ASLR protection (one random load address for the entire executable text and all its libraries, versus one for each object) - the need for complex single- to multi-threaded transition support code in various system libraries (mostly in libc). - slower load times. Yes, slower. A single statically-linked executable will load faster than the same program dynamically-linked. But a larger system than just one executable (e.g., the host OS, related applications, helper programs, ...) will load slower because multiple copies of common texts will not be sharable. If a major library like OpenSSL were to force operating systems to deal with the shortcomings of mixed process models and static linking, that would be a good thing. That's what OpenSSL would be doing by using -lpthread. > The C-library on many platforms is carefully designed to operate > efficiently and lock-less-ly in single-threaded applications, and to > only switch to thread-aware implementations of functions when the > pthread library is loaded. I don't think the loss of the lock-less optimizations should be of particular concern to OpenSSL: if that's a problem for a given OS, let its implementors deal with it. (They can do it, by, e.g., hot-swapping lock functions at pthread_create() call time rather than at the time that libpthread is loaded.) > In NetBSD, for example, the header file carefully > defines non-threaded (or rather lazily threaded only when pthread > is also loaded) versions of various pthread functions, see the > extract of pthread.h below my signature. It shouldn't be the loading of libpthread that causes transition to a threaded model (and, therefore, loss of single-threaded optimizations), but calling pthread_create(). If NetBSD really does the former, well, too bad: it really ought to be changed to do the latter. > Therefore, on any platform where the C-library is properly engineered > in this way (at least NetBSD and MacOS/X), we should not be > introducing -lpthread or definining "-D_REENTRANT", ... Nonetheless, this is good advice. If the necessary functionality from libpthread can be found in libc (or, in the case of thread-locals, in the compiler), then OpenSSL should avoid bringing in -lpthread. As long as they support seamless upgrade to threaded model via dlopen(), this is good advice. Of course, this does mean that OpenSSL needs more complexity in its configurator: to decide when to use -lpthread and when not to. > We are a thread-safe library, *not* a threaded library, and must > not introduce threading into threaded applications. That's a bit of a fairy tale. OpenSSL is not thread-safe when called from other libraries, as a) it's not their place to initialize OpenSSL's lock callbacks, b) the program might not do it either, c) OpenSSL defaults do no locking, d) the lock callback initialization interfaces assume no races to initialize lock callbacks, which means that other libraries can't safely initialize them (in practice one library is likely to always win the race, still). It's time to fix this. If OpenSSL will now require -lpthread, then it gets easier, certainly, so I'm not exactly against OpenSSL requiring -lpthread! ;) > We should think carefully about which platforms get async support > (perhaps one at time, and before it has been tested), and whether > "-pthread" is an acceptable penalty for any potential future > advantage of async support (none at present). > > Thoughts? Comments? See above. I'm not sure you'll be please with mine :) > -- > Viktor. > > [NetBSD header commentary extracts elided] Nico -- From nico at cryptonector.com Mon Nov 23 18:28:44 2015 From: nico at cryptonector.com (Nico Williams) Date: Mon, 23 Nov 2015 12:28:44 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151123015347.GJ18315@mournblade.imrryr.org> References: <20151123015347.GJ18315@mournblade.imrryr.org> Message-ID: <20151123182843.GB9363@localhost> On Mon, Nov 23, 2015 at 01:53:47AM +0000, Viktor Dukhovni wrote: [NetBSD header commentary extracts:] > /* > * Use macros to rename many pthread functions to the corresponding > * libc symbols which are either trivial/no-op stubs or the real No renaming is necessary if one's link-editor and RTLD support filters... An ELF filter is a forwarding saying that the implementation of a symbol in the filter object is to be found elsewhere, e.g., in some other object. In Solaris/Illumos this is used to maintain backwards compatibility when symbols get moved from one library to another. E.g., libpthread and libdl moved into libc, but they remain as filters so that objects linked with those old libraries will a) still find them, b) still find the symbols the expect in them, c) get the correct implementations of those symbols from the object now providing them (here: libc). Filters are awesome. Lack of universal support for them is very frustrating. On Linux, for example, it's possible to create filters with strong link-editor-fu, but the RTLD does not support them. > * thing, depending on whether libpthread is linked in to the > * program. This permits code, particularly libraries that do not > * directly use threads but want to be thread-safe in the presence of > * threaded callers, to use pthread mutexes and the like without > * unnecessairly including libpthread in their linkage. Just move these into libc, lock stock and barrel, and if you want to have fast versions for the single-threaded case, just arrange for slower versions to get hot-patched-in when pthread_create() is first called. Or even just use a branch/computed jump (whichever is faster) to avoid having to hot-patch. It's important that pthread_mutex_init/lock/trylock/unlock/destroy work correctly even in the optimized single-threaded case. The main thread might init and acquire some locks then create a second thread that will block acquiring those locks. > * Left out of this list are functions that can't sensibly be trivial > * or no-op stubs in a single-threaded process (pthread_create, > * pthread_kill, pthread_detach), functions that normally block and > * wait for another thread to do something (pthread_join), and Just move them into libc anyways. > * functions that don't make sense without the previous functions > * (pthread_attr_*). The pthread_cond_wait and pthread_cond_timedwait > * functions are useful in implementing certain protection mechanisms, > * though a non-buggy app shouldn't end up calling them in > * single-threaded mode. > * > * The rename is done as: > * #define pthread_foo __libc_foo > * instead of > * #define pthread_foo(x) __libc_foo((x)) > * in order that taking the address of the function ("func = > * &pthread_foo;") continue to work. > * > * POSIX/SUSv3 requires that its functions exist as functions (even if > * macro versions exist) and specifically that "#undef pthread_foo" is > * legal and should not break anything. Code that does such will not > * successfully get the stub behavior implemented here and will > * require libpthread to be linked in. > */ All the more reason to not rename these symbols! All you need is ELF filter support. Nico -- From matt at openssl.org Mon Nov 23 20:34:29 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 23 Nov 2015 20:34:29 +0000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151123174937.GA9363@localhost> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123174937.GA9363@localhost> Message-ID: <56537855.2020400@openssl.org> On 23/11/15 17:49, Nico Williams wrote: > [Resend, with slight edits.] > > [Viktor asked me for my advice on this issue and bounced me the post > that I'm following up to. -Nico] > > The summary of what I've to say is that making libcrypto and libssl need > -lpthread is something that does require discussion, as it will have > detrimental effects on some users. Personally, I think that those > detrimental effects are a good thing (see below), but nonetheless I > encourage you to discuss whether this is actually what OpenSSL should > do. In particular, it may be possible to avoid -lpthread on some > systems and still get a subset of lipthread functionality from libc or > the compiler (e.g., thread-locals), and that may be worth doing. > > On a slightly related note, I asked and Viktor tells me that fiber > stacks are allocated with malloc(). I would prefer that they were > allocated with mmap(), because then you get a guard page. A guard page > would allow one to safely tune down fiber stack size to the whatever > OpenSSL actually needs for a given use. Interesting. I'll take a look at that. > Still, if -lpthread avoidance were still desired, you'd have to find an > alternative to pthread_key_create(), pthread_getspecific(), and friends. Just a point to note about this. The async code that introduced this has 3 different implementations: - posix - windows - null The detection code will check if you have a suitable posix or windows implementation and use that. Otherwise the fallback position is to use the null implementation. With "null" everything will compile and run but you won't be able to use any of the new async functionality. Only the posix implementation uses the pthread* functions (and only for thread local storage). Part of the requirement of the posix detection code is that you have "Configured" with "threads" enabled. This is the default. However it is possible to explicitly configure with "no-threads". This suppresses stuff like the "-DRENENTERANT" flag. It now will also force the use of the null implementation for async and hence will not use any of the pthread functions. One other option we could pursue is to use the "__thread" syntax for thread local variables and avoid the need for libpthread altogether. An earlier version of the code did this. I have not found a way to reliably detect at compile time the capability to do this and my understanding is that this is a lot less portable. Matt From beldmit at gmail.com Mon Nov 23 20:35:17 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 23 Nov 2015 23:35:17 +0300 Subject: [openssl-dev] PBE_UNICODE In-Reply-To: <564F7847.2060902@openssl.org> References: <564E4A37.9010104@openssl.org> <564EE32B.4070706@openssl.org> <564EFA76.2030804@openssl.org> <564F2561.8050300@openssl.org> <564F7847.2060902@openssl.org> Message-ID: Dear Andy, On Fri, Nov 20, 2015 at 10:45 PM, Andy Polyakov wrote: > > > The test example was provide by the authors of specification. There are > > also examples in the document. May be it will be useful. > > We are apparently talking about slightly different things. Well, they > are somewhat related, but not quite the same. It's just additional angle > to cover. > Ok. Let's try to collect all the things. 1. We have a lack of Internet-wide specification regarding processing the multibyte characters in PKCS#12. 2. We have the openssl code with 2 variants of such processing that can be switched by the PBE_UNICODE define. 3. We have a "Russian" variant of specification. I am interested mostly in compatibility between the openssl implementation and "Russian" one when the password contains ASCII or Cyrillic characters. How can I help? -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico at cryptonector.com Mon Nov 23 20:48:25 2015 From: nico at cryptonector.com (Nico Williams) Date: Mon, 23 Nov 2015 14:48:25 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <56537855.2020400@openssl.org> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> Message-ID: <20151123204824.GC9363@localhost> On Mon, Nov 23, 2015 at 08:34:29PM +0000, Matt Caswell wrote: > On 23/11/15 17:49, Nico Williams wrote: > > On a slightly related note, I asked and Viktor tells me that fiber > > stacks are allocated with malloc(). I would prefer that they were > > allocated with mmap(), because then you get a guard page. A guard page > > would allow one to safely tune down fiber stack size to the whatever > > OpenSSL actually needs for a given use. > > Interesting. I'll take a look at that. Please do. It will make this much safer. Also, you might want to run some experiments to find the best stack size on each platform. The smaller the stack you can get away with, the better. > > Still, if -lpthread avoidance were still desired, you'd have to find an > > alternative to pthread_key_create(), pthread_getspecific(), and friends. > > Just a point to note about this. The async code that introduced this has > 3 different implementations: > > - posix > - windows > - null > > The detection code will check if you have a suitable posix or windows > implementation and use that. Otherwise the fallback position is to use > the null implementation. With "null" everything will compile and run but > you won't be able to use any of the new async functionality. > > Only the posix implementation uses the pthread* functions (and only for > thread local storage). Part of the requirement of the posix detection > code is that you have "Configured" with "threads" enabled. This is the > default. However it is possible to explicitly configure with > "no-threads". This suppresses stuff like the "-DRENENTERANT" flag. It > now will also force the use of the null implementation for async and > hence will not use any of the pthread functions. Ah, I see. I think that's fine. Maybe Viktor misunderstood this? > One other option we could pursue is to use the "__thread" syntax for > thread local variables and avoid the need for libpthread altogether. An > earlier version of the code did this. I have not found a way to reliably > detect at compile time the capability to do this and my understanding is > that this is a lot less portable. I use this in an autoconf project (I know, OpenSSL doesn't use autoconf): dnl Thread local storage have___thread=no AC_MSG_CHECKING(for thread-local storage) AC_LINK_IFELSE([AC_LANG_SOURCE([ static __thread int x ; int main () { x = 123; return x; } ])], have___thread=yes) if test $have___thread = yes; then AC_DEFINE([HAVE___THREAD],1,[Define to 1 if the system supports __thread]) fi AC_MSG_RESULT($have___thread) Is there something wrong with that that I should know? I suppose the test could use threads to make real sure that it's getting thread- locals, in case the compiler is simply ignoring __thread. Are there compilers that ignore __thread?? Nico -- From paul.dale at oracle.com Mon Nov 23 21:56:15 2015 From: paul.dale at oracle.com (Paul Dale) Date: Tue, 24 Nov 2015 07:56:15 +1000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151123054139.GB11308@localhost> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123054139.GB11308@localhost> Message-ID: <3165858.AMXWLaS1CV@acid> Somewhat tangentially related to this is the how thread locking in OpenSSL is slowing things up. We've been doing some connection establishment performance analysis recently and have discovered a lot of waiting on locks is occurring. By far the worst culprit is CRYPTO_LOCK_EVP_PKEY in CRYPTO_add_lock calls. Changing these to gcc's atomic add operations (__sync_add_and_fetch) improved things significantly: base OpenSSL 11935 connections/s 85% CPU utilisation with Atomic Change 16465 connections/s 22% CPU utilisation So fifty percent more connections for a quarter the CPU. At this point a number of other locks are causing the slow down. Now, I'm not sure if such a change would be interesting to the community or not, but there definitely is room for significant gains in the multi threaded locking. Ignoring the atomic operations and moving to a separate lock per reference count would likely save a an amount of blocking -- is this a suitable use for dynamic locks? I also submitted a bug report and fix recently [openssl.org #4135] to do with threading, which will hopefully get included eventually. Regards, Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Mon Nov 23 22:08:32 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Mon, 23 Nov 2015 23:08:32 +0100 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151123204824.GC9363@localhost> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> <20151123204824.GC9363@localhost> Message-ID: <20151123220832.GA17864@roeckx.be> On Mon, Nov 23, 2015 at 02:48:25PM -0600, Nico Williams wrote: > > I use this in an autoconf project (I know, OpenSSL doesn't use autoconf): > > dnl Thread local storage > have___thread=no > AC_MSG_CHECKING(for thread-local storage) > AC_LINK_IFELSE([AC_LANG_SOURCE([ > static __thread int x ; > int main () { x = 123; return x; } > ])], have___thread=yes) > if test $have___thread = yes; then > AC_DEFINE([HAVE___THREAD],1,[Define to 1 if the system supports __thread]) > fi > AC_MSG_RESULT($have___thread) > > Is there something wrong with that that I should know? I suppose the > test could use threads to make real sure that it's getting thread- > locals, in case the compiler is simply ignoring __thread. Are there > compilers that ignore __thread?? I think that we currently don't do any compile / link test to detect features but that we instead explicitly say so for each platform. Anyway, the gcc the documentation is here: https://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html TLS support clearly isn't supported everywhere. Kurt From matt at openssl.org Mon Nov 23 22:18:27 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 23 Nov 2015 22:18:27 +0000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <3165858.AMXWLaS1CV@acid> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123054139.GB11308@localhost> <3165858.AMXWLaS1CV@acid> Message-ID: <565390B3.2030200@openssl.org> On 23/11/15 21:56, Paul Dale wrote: > Somewhat tangentially related to this is the how thread locking in > OpenSSL is slowing things up. Alessandro has submitted an interesting patch to provide a much better threading API. See: https://github.com/openssl/openssl/pull/451 I'm not sure what the current status of this is though. Matt From rsalz at akamai.com Mon Nov 23 22:19:57 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 23 Nov 2015 22:19:57 +0000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <565390B3.2030200@openssl.org> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123054139.GB11308@localhost> <3165858.AMXWLaS1CV@acid> <565390B3.2030200@openssl.org> Message-ID: <042af4dde5e042d7964d66dc56094684@usma1ex-dag1mb1.msg.corp.akamai.com> > https://github.com/openssl/openssl/pull/451 > I'm not sure what the current status of this is though. I've made several comments I think need to be addressed before we should merge it. From paul.dale at oracle.com Mon Nov 23 22:47:20 2015 From: paul.dale at oracle.com (Paul Dale) Date: Tue, 24 Nov 2015 08:47:20 +1000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <565390B3.2030200@openssl.org> References: <20151123015347.GJ18315@mournblade.imrryr.org> <3165858.AMXWLaS1CV@acid> <565390B3.2030200@openssl.org> Message-ID: <1871521.Ze0LeRZOta@acid> Thanks for the quick reply. That patch looks much improved on this front. We'll wait for the changes and then retest performance. Thanks again, Pauli On Mon, 23 Nov 2015 10:18:27 PM Matt Caswell wrote: > > On 23/11/15 21:56, Paul Dale wrote: > > Somewhat tangentially related to this is the how thread locking in > > OpenSSL is slowing things up. > > Alessandro has submitted an interesting patch to provide a much better > threading API. See: > > https://github.com/openssl/openssl/pull/451 > > I'm not sure what the current status of this is though. > > Matt > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From alessandro at ghedini.me Mon Nov 23 23:11:37 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Mon, 23 Nov 2015 23:11:37 +0000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <3165858.AMXWLaS1CV@acid> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123054139.GB11308@localhost> <3165858.AMXWLaS1CV@acid> Message-ID: <20151123231136.GA6451@kronk.local> On Tue, Nov 24, 2015 at 07:56:15am +1000, Paul Dale wrote: > Somewhat tangentially related to this is the how thread locking in OpenSSL is > slowing things up. > > We've been doing some connection establishment performance analysis recently > and have discovered a lot of waiting on locks is occurring. By far the worst > culprit is CRYPTO_LOCK_EVP_PKEY in CRYPTO_add_lock calls. Changing these to > gcc's atomic add operations (__sync_add_and_fetch) improved things > significantly: > > base OpenSSL 11935 connections/s 85% CPU utilisation > with Atomic Change 16465 connections/s 22% CPU utilisation > > So fifty percent more connections for a quarter the CPU. Is this TLS connections? > At this point a number of other locks are causing the slow down. I'd like to know more... > Now, I'm not sure if such a change would be interesting to the community or > not, but there definitely is room for significant gains in the multi threaded > locking. Ignoring the atomic operations and moving to a separate lock per > reference count would likely save a an amount of blocking -- is this a > suitable use for dynamic locks? As Matt mentioned, I'm curently working exactly on this. Would it be possible for you to share your testing method and code? I'd like to verify that my patches actually go in the right direction before having them merged (or maybe you could do your tests on top of my patches, they should mostly work fine even if the work is not complete yet, I think). Thanks From nico at cryptonector.com Mon Nov 23 23:28:18 2015 From: nico at cryptonector.com (Nico Williams) Date: Mon, 23 Nov 2015 17:28:18 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <565390B3.2030200@openssl.org> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123054139.GB11308@localhost> <3165858.AMXWLaS1CV@acid> <565390B3.2030200@openssl.org> Message-ID: <20151123232817.GD9363@localhost> On Mon, Nov 23, 2015 at 10:18:27PM +0000, Matt Caswell wrote: > On 23/11/15 21:56, Paul Dale wrote: > > Somewhat tangentially related to this is the how thread locking in > > OpenSSL is slowing things up. > > Alessandro has submitted an interesting patch to provide a much better > threading API. See: > > https://github.com/openssl/openssl/pull/451 > > I'm not sure what the current status of this is though. I'll have to look myself. A while back I posted a link to a not-yet-complete attempt to make all the lock (and threadid...) callbacks automatically initialized correctly/safely on Windows and Unix. It may be a good idea to rethink locking completely. Nico -- From pwalten at au1.ibm.com Mon Nov 23 11:53:15 2015 From: pwalten at au1.ibm.com (Peter Waltenberg) Date: Mon, 23 Nov 2015 21:53:15 +1000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151123204824.GC9363@localhost> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> <20151123204824.GC9363@localhost> Message-ID: <201511232354.tANNstpX000553@d23av06.au.ibm.com> " Please do. It will make this much safer. Also, you might want to run some experiments to find the best stack size on each platform. The smaller the stack you can get away with, the better. " It does, but it also requires code changes in a few places. probable_prime () in bn_prime.c being far and away the worst offender. We instrumented our test code so we could find out what the stack usage was, for libcrypto you can get it under 4k for 32 bit and under 8k for 64 bit code on x86 Linux. FYI, nothing elegant there, just have your code allocate and fill a large stack array then add check points further down to see how far you've eaten into it. " > > A guard page > > would allow one to safely tune down fiber stack size to the whatever > > OpenSSL actually needs for a given use. " Unless someone allocates a stack array larger than the size of the guard page and scribbles over another threads stack. This is another reason to never use large arrays on the stack. " Is there something wrong with that that I should know? I suppose the test could use threads to make real sure that it's getting thread- locals, in case the compiler is simply ignoring __thread. Are there compilers that ignore __thread?? " Only that it's a compile time choice and OpenSSL is currently 'thread neutral' at runtime, not at compile time ?. Compile time is easy, making this work at runtime is hard and occasionally is really valuable - i.e. way back in the dim distant path when Linux had multiple thread packages available. Peter From: Nico Williams To: openssl-dev at openssl.org Date: 24/11/2015 06:49 Subject: Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread Sent by: "openssl-dev" On Mon, Nov 23, 2015 at 08:34:29PM +0000, Matt Caswell wrote: > On 23/11/15 17:49, Nico Williams wrote: > > On a slightly related note, I asked and Viktor tells me that fiber > > stacks are allocated with malloc(). I would prefer that they were > > allocated with mmap(), because then you get a guard page. A guard page > > would allow one to safely tune down fiber stack size to the whatever > > OpenSSL actually needs for a given use. > > Interesting. I'll take a look at that. Please do. It will make this much safer. Also, you might want to run some experiments to find the best stack size on each platform. The smaller the stack you can get away with, the better. > > Still, if -lpthread avoidance were still desired, you'd have to find an > > alternative to pthread_key_create(), pthread_getspecific(), and friends. > > Just a point to note about this. The async code that introduced this has > 3 different implementations: > > - posix > - windows > - null > > The detection code will check if you have a suitable posix or windows > implementation and use that. Otherwise the fallback position is to use > the null implementation. With "null" everything will compile and run but > you won't be able to use any of the new async functionality. > > Only the posix implementation uses the pthread* functions (and only for > thread local storage). Part of the requirement of the posix detection > code is that you have "Configured" with "threads" enabled. This is the > default. However it is possible to explicitly configure with > "no-threads". This suppresses stuff like the "-DRENENTERANT" flag. It > now will also force the use of the null implementation for async and > hence will not use any of the pthread functions. Ah, I see. I think that's fine. Maybe Viktor misunderstood this? > One other option we could pursue is to use the "__thread" syntax for > thread local variables and avoid the need for libpthread altogether. An > earlier version of the code did this. I have not found a way to reliably > detect at compile time the capability to do this and my understanding is > that this is a lot less portable. I use this in an autoconf project (I know, OpenSSL doesn't use autoconf): dnl Thread local storage have___thread=no AC_MSG_CHECKING(for thread-local storage) AC_LINK_IFELSE([AC_LANG_SOURCE([ static __thread int x ; int main () { x = 123; return x; } ])], have___thread=yes) if test $have___thread = yes; then AC_DEFINE([HAVE___THREAD],1,[Define to 1 if the system supports __thread]) fi AC_MSG_RESULT($have___thread) Is there something wrong with that that I should know? I suppose the test could use threads to make real sure that it's getting thread- locals, in case the compiler is simply ignoring __thread. Are there compilers that ignore __thread?? Nico -- _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From openssl-users at dukhovni.org Mon Nov 23 23:56:54 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 23 Nov 2015 23:56:54 +0000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151123232817.GD9363@localhost> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123054139.GB11308@localhost> <3165858.AMXWLaS1CV@acid> <565390B3.2030200@openssl.org> <20151123232817.GD9363@localhost> Message-ID: <20151123235654.GY18315@mournblade.imrryr.org> On Mon, Nov 23, 2015 at 05:28:18PM -0600, Nico Williams wrote: > It may be a good idea to rethink locking completely. There is some glimmer of hope in that as various libcrypto structures become opaque, the locking moves from application code into the library. For example, we now have (yet to be documented): X509_up_ref() function, because applications can no longer directly manipulate the reference count. For compatibility with older releases Postfix now defines: src/tls/tls.h: #if OPENSSL_VERSION_NUMBER < 0x10100000L #define X509_up_ref(x) CRYPTO_add(&((x)->references), 1, CRYPTO_LOCK_X509) #endif Mind you, both the old and new interfaces assume that the X509 object (presumably freshly returned by some function) that the application wants to hang on somewhat longer than default, has not been deallocated by any other thread in the mean time! So in particular we are assuming that the caller's thread still "owns" structures that hold and are responsible for releasing at least one of the references. Anyway, with the locking moving into X509_up_ref(), the implementation moves into the library, where it becomes easier to switch to fine-grained locking. We may in more cases need "get1" analogues of existing "get0" interfaces, so that the user can obtain an already up-refed object from the library, and just have to call the appropriate "free" function at the end. Doing this requires a global review of the API, and filling in missing functions and documentation. :-( -- Viktor. From nico at cryptonector.com Tue Nov 24 00:41:32 2015 From: nico at cryptonector.com (Nico Williams) Date: Mon, 23 Nov 2015 18:41:32 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <201511232354.tANNstpX000553@d23av06.au.ibm.com> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> <20151123204824.GC9363@localhost> <201511232354.tANNstpX000553@d23av06.au.ibm.com> Message-ID: <20151124004131.GE9363@localhost> On Mon, Nov 23, 2015 at 09:53:15PM +1000, Peter Waltenberg wrote: > > " > Please do. It will make this much safer. Also, you might want to run > some experiments to find the best stack size on each platform. The > smaller the stack you can get away with, the better. > " > > It does, but it also requires code changes in a few places. probable_prime > () in bn_prime.c being far and away the worst offender. We instrumented our > test code so we could find out what the stack usage was, for libcrypto you > can get it under 4k for 32 bit and under 8k for 64 bit code on x86 Linux. Are you saying that using mmap() would be onerous? Something else? > FYI, nothing elegant there, just have your code allocate and fill a large > stack array then add check points further down to see how far you've eaten > into it. Sure. > " > > > A guard page > > > would allow one to safely tune down fiber stack size to the whatever > > > OpenSSL actually needs for a given use. > " > > Unless someone allocates a stack array larger than the size of the guard > page and scribbles over another threads stack. This is another reason to > never use large arrays on the stack. alloca() and VLAs aren't safe for allocating more bytes than fit in a guard page. One should not use alloca()/VLAs for anything larger than that. This is no reason not to have a guard page! This is a reason to have coding standards that address alloca()/VLAs. > " > Is there something wrong with that that I should know? I suppose the > test could use threads to make real sure that it's getting thread- > locals, in case the compiler is simply ignoring __thread. Are there > compilers that ignore __thread?? > " > > Only that it's a compile time choice and OpenSSL is currently 'thread > neutral' at runtime, not at compile time ?. OpenSSL is "thread-neutral" at run-time as to locks and thread IDs because of the lock/threadid callbacks. But here we're talking about a new feature (fibers) that uses thread-locals, and here using pthread thread locals (pthread_getspecific()) clearly means no longer being "thread-neutral" -- if I understand your definition of that term anyways. It's perfectly fine to use __thread in compiled code regardless of what threading library is used, provided -of course- that __thread was supported to begin with and that the compiler isn't lying. > Compile time is easy, making this work at runtime is hard and occasionally > is really valuable - i.e. way back in the dim distant path when Linux had > multiple thread packages available. If the compiler accepts __thread but allows it to break at run-time depending on the available threading libraries, then the compiler is broken and should now have allowed __thread to begin with. I can't find anything describing such brokenness. If you assert such brokenness exists then please post links or instructions for how to reproduce it. BTW, https://en.wikipedia.org/wiki/Thread-local_storage#C_and_C.2B.2B says that even Visual Studio supports thread-locals. Though there's a caveat that requires some care at configuration time: On Windows versions before Vista and Server 2008, __declspec(thread) works in DLLs only when those DLLs are bound to the executable, and will not work for those loaded with LoadLibrary() (a protection fault or data corruption may occur).[9] There must, of course, be compilers that don't support thread locals (pcc?). Wouldn't it be fair to say that OpenSSL simply doesn't support fibers on those compilers? I think so. Nico -- From rsalz at akamai.com Tue Nov 24 02:24:01 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 24 Nov 2015 02:24:01 +0000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <201511232354.tANNstpX000553@d23av06.au.ibm.com> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> <20151123204824.GC9363@localhost> <201511232354.tANNstpX000553@d23av06.au.ibm.com> Message-ID: <62eac234ea094223abf43d9721db85e6@usma1ex-dag1mb1.msg.corp.akamai.com> ? It does, but it also requires code changes in a few places. probable_prime() in bn_prime.c being far and away the worst offender. This is fixed in master which uses malloc and free. Actually, I think all egregious stack consumption has been fixed in master. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalten at au1.ibm.com Tue Nov 24 01:32:32 2015 From: pwalten at au1.ibm.com (Peter Waltenberg) Date: Tue, 24 Nov 2015 11:32:32 +1000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151124004131.GE9363@localhost> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> <20151123204824.GC9363@localhost> <201511232354.tANNstpX000553@d23av06.au.ibm.com> <20151124004131.GE9363@localhost> Message-ID: <201511240234.tAO2YmlJ025482@d23av04.au.ibm.com> I wasn't saying there was anything wrong with mmap(), just that guard pages only work if you can guarantee your overrun hits the guard page (and doesn't just step over it). Large stack allocations increase the odds of 'stepping over' the guard pages. It's still better than not having guard pages, but they aren't a hard guarantee that you won't have mysterious bugs still. You obviously realize that, but bn_prime() is the classic example of allocating very large chunks of memory on the stack. As for fibre's, I doubt it'll work in general, the issue there is simply the range of OS's OpenSSL supports. If you wire it in you still have to run with man+dog+world in the process, that's a hard ask. One of the good points about OpenSSL up until now, it tends to not break those big messy apps where a whole lot of independly developed code ends up in the same process. Peter From: Nico Williams To: openssl-dev at openssl.org Date: 24/11/2015 10:42 Subject: Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread Sent by: "openssl-dev" On Mon, Nov 23, 2015 at 09:53:15PM +1000, Peter Waltenberg wrote: > > " > Please do. It will make this much safer. Also, you might want to run > some experiments to find the best stack size on each platform. The > smaller the stack you can get away with, the better. > " > > It does, but it also requires code changes in a few places. probable_prime > () in bn_prime.c being far and away the worst offender. We instrumented our > test code so we could find out what the stack usage was, for libcrypto you > can get it under 4k for 32 bit and under 8k for 64 bit code on x86 Linux. Are you saying that using mmap() would be onerous? Something else? > FYI, nothing elegant there, just have your code allocate and fill a large > stack array then add check points further down to see how far you've eaten > into it. Sure. > " > > > A guard page > > > would allow one to safely tune down fiber stack size to the whatever > > > OpenSSL actually needs for a given use. > " > > Unless someone allocates a stack array larger than the size of the guard > page and scribbles over another threads stack. This is another reason to > never use large arrays on the stack. alloca() and VLAs aren't safe for allocating more bytes than fit in a guard page. One should not use alloca()/VLAs for anything larger than that. This is no reason not to have a guard page! This is a reason to have coding standards that address alloca()/VLAs. > " > Is there something wrong with that that I should know? I suppose the > test could use threads to make real sure that it's getting thread- > locals, in case the compiler is simply ignoring __thread. Are there > compilers that ignore __thread?? > " > > Only that it's a compile time choice and OpenSSL is currently 'thread > neutral' at runtime, not at compile time ?. OpenSSL is "thread-neutral" at run-time as to locks and thread IDs because of the lock/threadid callbacks. But here we're talking about a new feature (fibers) that uses thread-locals, and here using pthread thread locals (pthread_getspecific()) clearly means no longer being "thread-neutral" -- if I understand your definition of that term anyways. It's perfectly fine to use __thread in compiled code regardless of what threading library is used, provided -of course- that __thread was supported to begin with and that the compiler isn't lying. > Compile time is easy, making this work at runtime is hard and occasionally > is really valuable - i.e. way back in the dim distant path when Linux had > multiple thread packages available. If the compiler accepts __thread but allows it to break at run-time depending on the available threading libraries, then the compiler is broken and should now have allowed __thread to begin with. I can't find anything describing such brokenness. If you assert such brokenness exists then please post links or instructions for how to reproduce it. BTW, https://en.wikipedia.org/wiki/Thread-local_storage#C_and_C.2B.2B says that even Visual Studio supports thread-locals. Though there's a caveat that requires some care at configuration time: On Windows versions before Vista and Server 2008, __declspec(thread) works in DLLs only when those DLLs are bound to the executable, and will not work for those loaded with LoadLibrary() (a protection fault or data corruption may occur).[9] There must, of course, be compilers that don't support thread locals (pcc?). Wouldn't it be fair to say that OpenSSL simply doesn't support fibers on those compilers? I think so. Nico -- _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From openssl-users at dukhovni.org Tue Nov 24 03:03:26 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 24 Nov 2015 03:03:26 +0000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <201511240234.tAO2YmlJ025482@d23av04.au.ibm.com> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> <20151123204824.GC9363@localhost> <201511232354.tANNstpX000553@d23av06.au.ibm.com> <20151124004131.GE9363@localhost> <201511240234.tAO2YmlJ025482@d23av04.au.ibm.com> Message-ID: <20151124030326.GA18315@mournblade.imrryr.org> On Tue, Nov 24, 2015 at 11:32:32AM +1000, Peter Waltenberg wrote: > As for fibre's, I doubt it'll work in general, the issue there is simply > the range of OS's OpenSSL supports. If you wire it in you still have to run > with man+dog+world in the process, that's a hard ask. One of the good > points about OpenSSL up until now, it tends to not break those big messy > apps where a whole lot of independly developed code ends up in the same > process. It'll work because it has to be explicitly enabled by the application, the OpenSSL library will provide the support on sufficiently capable platforms, but they won't be used unless explicitly requested, and they're only useful if there's some sort of asynchronous crypto engine available. They're light-weight glue to facilitate new kinds of low-overhead asynchronous operations. The use of fibres will be rather rare until such engines become commonplace. -- Viktor. From nico at cryptonector.com Tue Nov 24 07:13:56 2015 From: nico at cryptonector.com (Nico Williams) Date: Tue, 24 Nov 2015 01:13:56 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <201511240234.tAO2YmlJ025482@d23av04.au.ibm.com> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> <20151123204824.GC9363@localhost> <201511232354.tANNstpX000553@d23av06.au.ibm.com> <20151124004131.GE9363@localhost> <201511240234.tAO2YmlJ025482@d23av04.au.ibm.com> Message-ID: <20151124071355.GF9363@localhost> On Tue, Nov 24, 2015 at 11:32:32AM +1000, Peter Waltenberg wrote: > I wasn't saying there was anything wrong with mmap(), just that guard pages > only work if you can guarantee your overrun hits the guard page (and > doesn't just step over it). Large stack allocations increase the odds of > 'stepping over' the guard pages. It's still better than not having guard > pages, but they aren't a hard guarantee that you won't have mysterious bugs > still. > > You obviously realize that, but bn_prime() is the classic example of > allocating very large chunks of memory on the stack. Sure. Rich Salz claims this is all fixed in master, so guard pages strike me as a plus, not a wash. > As for fibre's, I doubt it'll work in general, the issue there is simply > the range of OS's OpenSSL supports. If you wire it in you still have to run > with man+dog+world in the process, that's a hard ask. One of the good > points about OpenSSL up until now, it tends to not break those big messy > apps where a whole lot of independly developed code ends up in the same > process. That's... a joke, right? OpenSSL very much does "break those big messy apps ...". I don't see the fibers project making that worse, nor better -- it's neutral. Let me give you some examples. Using Heimdal's libgssapi from Java JGSS (with the JNI GSS wrapper) blows up due to no one initializing OpenSSL's lock callbacks. Heimdal, of course, uses OpenSSL. Who should be initializing the lock callbacks? Not the JVM -- why should it know/assume that some library used via dlopen() will want OpenSSL? But it's not a library's place to initialize OpenSSL's lock callbacks either! Suppose a Java program were loading via dlopen() *two* libraries that use OpenSSL, and suppose different threads are racing to do this. This happens, and it happens because OpenSSL is used in so many *libraries*, not just *programs*. OpenSSL is a prime case of how a library meant for use by programs comes to be used by libraries. Another example is PKCS#11. That's no excuse. Use by libraries must be supported. And historically OpenSSL has been very bad at keeping its ABI backwards-compatible, so DLL Hell cases often involve OpenSSL. The more layers: the higher the likelihood of breakage involving OpenSSL. All threaded pluggable-software-using software (name services switch, PAM, JNI, ...) is vulnerable to these problems. If the OpenSSL team finally decides to do something about sane locking by default, then it will be a huge improvement. If this thread provides the impetus, so much the better. Nico -- From openssl-users at dukhovni.org Tue Nov 24 07:20:30 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 24 Nov 2015 02:20:30 -0500 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151124071355.GF9363@localhost> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> <20151123204824.GC9363@localhost> <201511232354.tANNstpX000553@d23av06.au.ibm.com> <20151124004131.GE9363@localhost> <201511240234.tAO2YmlJ025482@d23av04.au.ibm.com> <20151124071355.GF9363@localhost> Message-ID: > On Nov 24, 2015, at 2:13 AM, Nico Williams wrote: > > If the OpenSSL team finally decides to do something about sane locking > by default, then it will be a huge improvement. If this thread provides > the impetus, so much the better. I hope that happens. It would certainly make a big contribution to the ecosystem around OpenSSL. The key question is whether there is a right someone outside the team to step forward and write the code, or whether it needs be developed by an OpenSSL team member (and whether cycles for that are available in the near term). I hope that one or the other may come to pass. -- Viktor. From rt at openssl.org Tue Nov 24 11:06:44 2015 From: rt at openssl.org (Pascal Cuoq via RT) Date: Tue, 24 Nov 2015 11:06:44 +0000 Subject: [openssl-dev] [openssl.org #4155] In function int_thread_del_item, when hash == int_thread_hash, one is passed to free and the other is used in a comparison In-Reply-To: References: Message-ID: This issue is similar in nature to 4151 (http://www.mail-archive.com/openssl-dev at openssl.org/msg40950.html ): it is about a dangling pointer being used, but not used for dereferencing, so it's not a memory error. The dangling pointer is used in a comparison. The function int_thread_del_item can reach the point were it calls ?lh_ERR_STATE_free(int_thread_hash);? with hash == int_thread_hash. That attached patch prints a message like ?hash == int_thread_hash == 0xb2a6d0? when this happens. Just after the call to lh_ERR_STATE_free, both hash and int_thread_hash contain dangling pointers. The variable int_thread_hash is immediately set to NULL. The problem that I am reporting is that just afterwards, &hash is passed to the function int_thread_release: https://github.com/openssl/openssl/blob/079a1a9014b89661f0a612a5a9724ad9c77f21a3/crypto/err/err.c#L412 In that function, the argument ?hash? points to the local variable ?hash? of int_thread_del_item (which contains a dangling pointer). Thus the comparison ?*hash == NULL? involves a dangling pointer: https://github.com/openssl/openssl/blob/079a1a9014b89661f0a612a5a9724ad9c77f21a3/crypto/err/err.c#L343 With the attached patch, executing test/enginetest reproduces the problem for me: $ ./enginetest enginetest beginning ? Tests completed happily hash == int_thread_hash == 0x1a3f6d0 Now using *hash (0x1a3f6d0) in a comparison -------------- next part -------------- A non-text attachment was scrubbed... Name: show_pointers.patch Type: application/octet-stream Size: 793 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From jifl at eCosCentric.com Tue Nov 24 15:16:59 2015 From: jifl at eCosCentric.com (Jonathan Larmour) Date: Tue, 24 Nov 2015 15:16:59 +0000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <56537855.2020400@openssl.org> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> Message-ID: <56547F6B.5060508@eCosCentric.com> On 23/11/15 20:34, Matt Caswell wrote: > On 23/11/15 17:49, Nico Williams wrote: > >> Still, if -lpthread avoidance were still desired, you'd have to find an >> alternative to pthread_key_create(), pthread_getspecific(), and friends. > > Just a point to note about this. The async code that introduced this has > 3 different implementations: > > - posix > - windows > - null > > The detection code will check if you have a suitable posix or windows > implementation and use that. Otherwise the fallback position is to use > the null implementation. With "null" everything will compile and run but > you won't be able to use any of the new async functionality. I hope there will be the ability to plug in different operating systems and it's not hard coded to just these choices. There are embedded systems which use OpenSSL which do not have POSIX thread APIs (POSIX is very heavyweight for many). For example, GCC abstracts their threading dependenencies with a "gthread" API which OS implementers can write against. What would be bad would be direct calls to pthread* dotted around the OpenSSL code base. > One other option we could pursue is to use the "__thread" syntax for > thread local variables and avoid the need for libpthread altogether. An > earlier version of the code did this. I have not found a way to reliably > detect at compile time the capability to do this and my understanding is > that this is a lot less portable. Behind the scenes, if pthreads are available on an OS, then the compiler will probably just end up using pthread functions anyway, meaning there's no advantage over having just linked against libpthread. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine From matt at openssl.org Tue Nov 24 15:33:29 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 24 Nov 2015 15:33:29 +0000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <56547F6B.5060508@eCosCentric.com> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> <56547F6B.5060508@eCosCentric.com> Message-ID: <56548349.2060003@openssl.org> On 24/11/15 15:16, Jonathan Larmour wrote: > On 23/11/15 20:34, Matt Caswell wrote: >> On 23/11/15 17:49, Nico Williams wrote: >> >>> Still, if -lpthread avoidance were still desired, you'd have to find an >>> alternative to pthread_key_create(), pthread_getspecific(), and friends. >> >> Just a point to note about this. The async code that introduced this has >> 3 different implementations: >> >> - posix >> - windows >> - null >> >> The detection code will check if you have a suitable posix or windows >> implementation and use that. Otherwise the fallback position is to use >> the null implementation. With "null" everything will compile and run but >> you won't be able to use any of the new async functionality. > > I hope there will be the ability to plug in different operating systems > and it's not hard coded to just these choices. There are embedded systems > which use OpenSSL which do not have POSIX thread APIs (POSIX is very > heavyweight for many). > > For example, GCC abstracts their threading dependenencies with a "gthread" > API which OS implementers can write against. What would be bad would be > direct calls to pthread* dotted around the OpenSSL code base. We are talking specifically about the new async functionality here. The three implementations are all you get for that. That has no impact on the rest of OpenSSL functionality. So if you happen to be on a non-posix and non-windows platform then OpenSSL will function as it does today. You just don't get the new async functionality on top. There are pthread references in one (internal) header file and one c source code file. If the new threading API discussed elsewhere in this thread goes ahead, then those references would be replaced with calls to that instead. Matt From hkario at redhat.com Mon Nov 23 12:19:10 2015 From: hkario at redhat.com (Hubert Kario) Date: Mon, 23 Nov 2015 13:19:10 +0100 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <564F7B83.8050902@av8n.com> References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <20151119192853.GO18315@mournblade.imrryr.org> <564F7B83.8050902@av8n.com> Message-ID: <1538388.BThJrABXJb@pintsize.usersys.redhat.com> On Friday 20 November 2015 12:58:59 John Denker wrote: > On 11/19/2015 12:28 PM, Viktor Dukhovni wrote: > > What algorithms people use on > > their own data is their choice and risk decision not ours. > > To say the same thing yet another way, fundamentally we have a > communication problem, or rather two separate communication > problems: > A) The experts on this list know that certain crypto primitives > are "broken or outdated". This needs to be communicated to the > people who are actually in a position to make and implement > policy. > B) There is some question as to whether users in the field have > received message (A) and successfully ended all use of the > deprecated primitives. It would be nice if the people who > know the status could communicate this back to the developers. There are certain situations in which using "broken or outdated" algorithms is both secure and unavoidable. See my email from Wed, 18 Nov 2015 14:05:07 +0100. And to repeat myself: TLS is *not* the only way OpenSSL is used. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From for-gmane at mutluit.com Tue Nov 24 17:33:43 2015 From: for-gmane at mutluit.com (U.Mutlu) Date: Tue, 24 Nov 2015 18:33:43 +0100 Subject: [openssl-dev] [libcrypto EVP] valgrind reports many memory leaks in wiki-example In-Reply-To: References: Message-ID: U.Mutlu wrote on 11/23/2015 06:43 AM: > U.Mutlu wrote on 11/23/2015 06:32 AM: >> Hi, >> running the following example from the openssl wiki site under valgrind >> gives many memory-leaks in the underlying library functions: >> https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption >> >> $ valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all >> --track-origins=yes -v ./a.out &>valgrind-output.txt >> >> Attached is the valgrind-output. It says: >> 34 not-freed blocks >> >> Are these maybe false-positives? The leak summary in the output says this: >> >> ==9895== LEAK SUMMARY: >> ==9895== definitely lost: 0 bytes in 0 blocks >> ==9895== indirectly lost: 0 bytes in 0 blocks >> ==9895== possibly lost: 0 bytes in 0 blocks >> ==9895== still reachable: 2,632 bytes in 34 blocks >> ==9895== suppressed: 0 bytes in 0 blocks Has nobody a clue what the above output means? From rsalz at akamai.com Tue Nov 24 17:37:06 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 24 Nov 2015 17:37:06 +0000 Subject: [openssl-dev] [libcrypto EVP] valgrind reports many memory leaks in wiki-example In-Reply-To: References: Message-ID: <2768ca5d7a78422aa8b40ca2e66f37d6@usma1ex-dag1mb1.msg.corp.akamai.com> >> Attached is the valgrind-output. It says: >> 34 not-freed blocks The sample program doesn't clean up everything. Look at the function apps_shutdown in apps/openssl.c (in master) From kurt at roeckx.be Tue Nov 24 18:00:00 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 24 Nov 2015 19:00:00 +0100 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <56547F6B.5060508@eCosCentric.com> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> <56547F6B.5060508@eCosCentric.com> Message-ID: <20151124175959.GA8987@roeckx.be> On Tue, Nov 24, 2015 at 03:16:59PM +0000, Jonathan Larmour wrote: > On 23/11/15 20:34, Matt Caswell wrote: > > One other option we could pursue is to use the "__thread" syntax for > > thread local variables and avoid the need for libpthread altogether. An > > earlier version of the code did this. I have not found a way to reliably > > detect at compile time the capability to do this and my understanding is > > that this is a lot less portable. > > Behind the scenes, if pthreads are available on an OS, then the compiler > will probably just end up using pthread functions anyway, meaning there's > no advantage over having just linked against libpthread. __thread can be used in something that doesn't use threads. It gets put in a different section in the elf file (.tbss, .tdata). But that still requires that things like the dynamic loader support it. Kurt From for-gmane at mutluit.com Tue Nov 24 19:42:27 2015 From: for-gmane at mutluit.com (U.Mutlu) Date: Tue, 24 Nov 2015 20:42:27 +0100 Subject: [openssl-dev] [libcrypto EVP] valgrind reports many memory leaks in wiki-example In-Reply-To: <2768ca5d7a78422aa8b40ca2e66f37d6@usma1ex-dag1mb1.msg.corp.akamai.com> References: <2768ca5d7a78422aa8b40ca2e66f37d6@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Salz, Rich wrote on 11/24/2015 06:37 PM: >>> Attached is the valgrind-output. It says: >>> 34 not-freed blocks > > The sample program doesn't clean up everything. Look at the function apps_shutdown in apps/openssl.c (in master) Ok, thx. After the following additions to the said sample the mem-leaks disappear: #include // extracted from the macro "apps_shutdown()" in file openssl/apps apps.h void my_libcrypto_shutdown() { CONF_modules_unload(1); EVP_cleanup(); ENGINE_cleanup(); CRYPTO_cleanup_all_ex_data(); ERR_remove_state(0); ERR_free_strings(); } // at the end of the app call this: my_libcrypto_shutdown(); -- U.Mutlu From rt at openssl.org Tue Nov 24 21:18:56 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Tue, 24 Nov 2015 21:18:56 +0000 Subject: [openssl-dev] [openssl.org #4110] [PATCH] fix ssl_new() error handling on out of memory condition In-Reply-To: <20151124211852.GA25252@roeckx.be> References: <20151027200838.GJ21257@haproxy.com> <20151124211852.GA25252@roeckx.be> Message-ID: This should be fixed now. Kurt From rt at openssl.org Tue Nov 24 21:19:18 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Tue, 24 Nov 2015 21:19:18 +0000 Subject: [openssl-dev] [openssl.org #4111] [PATCH] fix ssl3_free NULL dereference on out of memory condition In-Reply-To: <20151124211918.GB25252@roeckx.be> References: <20151027200952.GK21257@haproxy.com> <20151124211918.GB25252@roeckx.be> Message-ID: This should be fixed now. Kurt From rt at openssl.org Tue Nov 24 22:06:55 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Tue, 24 Nov 2015 22:06:55 +0000 Subject: [openssl-dev] [openssl.org #3910] [PATCH] Build correctly when no_des option is enabled In-Reply-To: <20151124220655.GA12047@roeckx.be> References: <20151124220655.GA12047@roeckx.be> Message-ID: On Sun, Jun 14, 2015 at 11:59:59PM +0000, 84.le0n via RT wrote: > > I've had the same problem Osvaldo Calles had when building OpenSSL with > no-des option enabled . > This patch simply add an #ifndef around the first if clause avoiding > EVP_des_ede3_wrap call. This at least causes a test suite error: /usr/bin/perl cms-test.pl CMS => PKCS#7 compatibility tests signed content DER format, RSA key: OK signed detached content DER format, RSA key: OK signed content test streaming BER format, RSA: OK signed content DER format, DSA key: OK signed detached content DER format, DSA key: OK signed detached content DER format, add RSA signer: OK signed content test streaming BER format, DSA key: OK signed content test streaming BER format, 2 DSA and 2 RSA keys: OK signed content test streaming BER format, 2 DSA and 2 RSA keys, no attributes: OK signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: OK signed content test streaming multipart S/MIME format, 2 DSA and 2 RSA keys: OK enveloped content test streaming S/MIME format, 3 recipients: generation error Makefile:334: recipe for target 'test_cms' failed make[1]: *** [test_cms] Error 1 I'm not sure what that code is trying to do, so I wonder if we should return an error in case EVP_CIPHER_type(cipher) == NID_des_ede3_cbc but OPENSSL_NO_DES is defined. Kurt From fweimer at redhat.com Wed Nov 25 12:02:29 2015 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 25 Nov 2015 13:02:29 +0100 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151123220832.GA17864@roeckx.be> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> <20151123204824.GC9363@localhost> <20151123220832.GA17864@roeckx.be> Message-ID: <5655A355.4060501@redhat.com> On 11/23/2015 11:08 PM, Kurt Roeckx wrote: > I think that we currently don't do any compile / link test to > detect features but that we instead explicitly say so for each > platform. > > Anyway, the gcc the documentation is here: > https://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html > > TLS support clearly isn't supported everywhere. The most portable approach is to switch C++11, which provides you thread-local variables with destructors (and you also get portable atomics). There are simply no standards-based C solutions as long as you have to support the Microsoft compiler under Windows. Florian From kurt at roeckx.be Wed Nov 25 17:48:34 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 25 Nov 2015 18:48:34 +0100 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <5655A355.4060501@redhat.com> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123174937.GA9363@localhost> <56537855.2020400@openssl.org> <20151123204824.GC9363@localhost> <20151123220832.GA17864@roeckx.be> <5655A355.4060501@redhat.com> Message-ID: <20151125174834.GA7307@roeckx.be> On Wed, Nov 25, 2015 at 01:02:29PM +0100, Florian Weimer wrote: > On 11/23/2015 11:08 PM, Kurt Roeckx wrote: > > > I think that we currently don't do any compile / link test to > > detect features but that we instead explicitly say so for each > > platform. > > > > Anyway, the gcc the documentation is here: > > https://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html > > > > TLS support clearly isn't supported everywhere. > > The most portable approach is to switch C++11, which provides you > thread-local variables with destructors (and you also get portable > atomics). There are simply no standards-based C solutions as long as > you have to support the Microsoft compiler under Windows. Please note that we use C, not C++. But C11 has the same atomics extentions as C++11. We're also currently still targetting C89/C90 (with some minor extentions), but I think we should try to use them if the platform supports it. Kurt From rt at openssl.org Wed Nov 25 19:33:01 2015 From: rt at openssl.org (Hannes Mezger via RT) Date: Wed, 25 Nov 2015 19:33:01 +0000 Subject: [openssl-dev] [openssl.org #4156] Wrong expectation of value of _IOB_ENTRIES with Visual Studio 2015 In-Reply-To: <5656089E.8010909@ascolab.com> References: <5656089E.8010909@ascolab.com> Message-ID: Hi, when using OpenSSL (1.0.1p) in our applications, we get the error 'No OPENSSL_Applink' when calling PEM_read_X509_CRL. We build both OpenSSL and the application using the same C runtime configuration (/MDd), using Visual Studio 2015 on Windows 10. After some hours of debugging and comparing with the same scenario using Visual Studio 2010, I discovered that _IOB_ENTRIES is defined differently in the two versions of Visual Studio: VS2015: c:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\stdio.h: #define _IOB_ENTRIES 3 VS2010: c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\stdio.h: #define _IOB_ENTRIES 20 Now there's code in openssl-1.0.1p\crypto\bio\bss_file.c that seems to expect _IOB_ENTRIES to have the value 20: # if defined(__MINGW32__) && defined(__MSVCRT__) && !defined(_IOB_ENTRIES) # define _IOB_ENTRIES 20 # endif # if defined(_IOB_ENTRIES) /* Safety net to catch purely internal BIO_set_fp calls */ if ((size_t)ptr >= (size_t)stdin && (size_t)ptr < (size_t)(stdin + _IOB_ENTRIES)) BIO_clear_flags(b, BIO_FLAGS_UPLINK); # endif # endif # ifdef UP_fsetmod if (b->flags & BIO_FLAGS_UPLINK) UP_fsetmod(b->ptr, (char)((num & BIO_FP_TEXT) ? 't' : 'b')); else # endif The 'safety net' does not work here, as _IOB_ENTRIES is too small in VS2015 and the flags don't get cleared (as for VS2010), so UP_fsetmod is being called which leads to the 'No OPENSSL_Applink' error. We kindly ask you to provide a solution for our problem, as we currently are not able to use OpenSSL in combination with VS2015. Linking the applink.c into our applications is no option for us, as we would have to deploy multiple C runtimes (one for OpenSSL and one for the application). Best regards, Hannes Mezger -- *Hannes Mezger* ascolab GmbH Tel.: +49 9131 691 124 Fax: +49 9131 691 128 Web: http://www.ascolab.com GPG-KeyId: 46EC1280 GPG-Fingerprint: D28A DE55 05FA 2FF3 8628 323A 1D6E 9EC8 46EC 1280 -- ascolab GmbH - Am Weichselgarten 7 - 91058 Erlangen - Germany Handelsregister/Commercial Register: Amtsgericht F?rth HRB 9360 Gesch?ftsf?hrer/Managing Directors: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrau? This email contains confidential information and is for the exclusive use of the addressee. If you are not the addressee, then any distribution, copying or use of this email is prohibited. If received in error, please advise the sender and delete immediately. We accept no liability for any loss or damage suffered by any person arising from use of this email. -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Nov 25 19:55:09 2015 From: rt at openssl.org (Mike Frysinger via RT) Date: Wed, 25 Nov 2015 19:55:09 +0000 Subject: [openssl-dev] [openssl.org #3738] [PATCH] tell make running subcommands are make based In-Reply-To: <20151125194544.GP23754@vapier.lan> References: <1425797389-3813-1-git-send-email-vapier@gentoo.org> <20151125194544.GP23754@vapier.lan> Message-ID: On 08 Mar 2015 20:26, Salz, Rich wrote: > > Lets add + to the rules we know are make based. > > Isn't that a gnu-make-only thing? looks to me like POSIX specifies it: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html#tag_20_76_13_03 -mike From rt at openssl.org Fri Nov 27 13:39:36 2015 From: rt at openssl.org (Tom Jay via RT) Date: Fri, 27 Nov 2015 13:39:36 +0000 Subject: [openssl-dev] [openssl.org #4157] Download Documentation In-Reply-To: References: Message-ID: Hello, Why is there no meaningul documentation on the OpenSSL download page? Why, if I'm building a SSL-enabled webserver, do I need to spend so much time on OpenSSL specifically? Why do the other tasks, of which there are many, not requires as much time as OpenSSL to compile, install and use, despite being equally complex? Could you imagine having to spend as much time on everything, that you do on OpenSSL, just to get it working? Useful steps would be as follows: 1. Provide meaningful documentation on the download page. Some kind of explanations of the versioning system would be useful, other than me trying to guess what the best version for me to download and install is. 2. Provde a summary of the installation steps. Something like Apache would be useful, where they just give you basic steps to get you up and running. 3. Some kind of useful examples of common usages of OpenSSL would be appreciated. I'm still trawling through the documentation trying to figure out how to do what I want to do and am relying heaving on 3rd party guides to figure out what I want to do. Thanks! Tom -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From for-gmane at mutluit.com Sat Nov 28 03:55:19 2015 From: for-gmane at mutluit.com (U.Mutlu) Date: Sat, 28 Nov 2015 04:55:19 +0100 Subject: [openssl-dev] [openssl.org #4157] Download Documentation In-Reply-To: References: Message-ID: Tom Jay via RT wrote on 11/27/2015 02:39 PM: > Hello, > > Why is there no meaningul documentation on the OpenSSL download page? Why, > if I'm building a SSL-enabled webserver, do I need to spend so much time on > OpenSSL specifically? Why do the other tasks, of which there are many, not > requires as much time as OpenSSL to compile, install and use, despite being > equally complex? Could you imagine having to spend as much time on > everything, that you do on OpenSSL, just to get it working? > > Useful steps would be as follows: > > 1. Provide meaningful documentation on the download page. Some kind of > explanations of the versioning system would be useful, other than me trying > to guess what the best version for me to download and install is. 2. Provde > a summary of the installation steps. Something like Apache would be useful, > where they just give you basic steps to get you up and running. 3. Some > kind of useful examples of common usages of OpenSSL would be appreciated. > I'm still trawling through the documentation trying to figure out how to do > what I want to do and am relying heaving on 3rd party guides to figure out > what I want to do. > > Thanks! > > Tom http://www.openssl.org/source/ "When building a release for the first time, please make sure to look at the README and INSTALL files in the distribution. If you have problems, look at the FAQ, which can also be found online." FAQ: http://www.openssl.org/docs/faq.html Manpages: http://www.openssl.org/docs/manmaster/ Or if you have the man pages installed locally --> see 'man openssl', 'man evp', 'man bio' etc. and the SEE ALSO references on those pages. On linux desktops it is easier/recommended to use the prebuilt version from the linux distribution (ie. via package management like on Debian: apt-get install libcrypto++-dev libcrypto++-doc libcrypto++-utils openssl ) -- U.Mutlu From rt at openssl.org Sun Nov 29 09:04:04 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Sun, 29 Nov 2015 09:04:04 +0000 Subject: [openssl-dev] [openssl.org #4158] GOST 2012 compatibility is broken by commit 28f4580c1e510ccf4278a20975c9bc3306f758d6 In-Reply-To: References: Message-ID: Hello OpenSSL Team, I found out that the commit 28f4580c1e510ccf4278a20975c9bc3306f758d6 breaks GOST 2012 client auth processing. If the call to the EVP_PKEY_get_default_digest_nid() function is unacceptable here, it can be replaced with the chain of if expressions (the patch is attached). BTW, what is a design policy in places when we have an enumeration of algorithms? I supposed that calling the implementation-provided callbacks is a right way (or at least better then case expressions or chain of ifs)... Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- index dcfb44f..0619507 100644 --- a/ssl/statem/statem_srvr.c +++ b/ssl/statem/statem_srvr.c @@ -3017,6 +3017,14 @@ MSG_PROCESS_RETURN tls_process_cert_verify(SSL *s, PACKET *pkt) #endif } else if (pkey->type == EVP_PKEY_RSA) { md = EVP_md5_sha1(); +#ifndef OPENSSL_NO_GOST + } else if (pkey->type == NID_id_GostR3410_2001) { + md = EVP_get_digestbynid(NID_id_GostR3411_94); + } else if (pkey->type == NID_id_GostR3410_2012_256) { + md = EVP_get_digestbynid(NID_id_GostR3411_2012_256); + } else if (pkey->type == NID_id_GostR3410_2012_512) { + md = EVP_get_digestbynid(NID_id_GostR3411_2012_512); +#endif } else { md = EVP_sha1(); } -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sun Nov 29 11:09:34 2015 From: rt at openssl.org (Srinivas Koripella via RT) Date: Sun, 29 Nov 2015 11:09:34 +0000 Subject: [openssl-dev] [openssl.org #4159] BUG ::: Null dereference in ssl3_free In-Reply-To: References: Message-ID: Description. We are dereferencing s->s3 in ssl3_free without checking if s->s3 is null or not. s->s3 can be null because of the below code path. SSL_new--> ssl3_new/tls1_new (via s->method->ssl_new) which allocates s3 and assigns s->s3 if successful. If not s->s3 will remain null as we memset entire contents of s to zero on allocation in SSL_new. However in SSL_new on return from the above s->method->ssl_new we go to err and call SSL_free which always calls s->method->ssl_free with us landing in ssl3_free with s->s3 as NULL. The fix should be to check for s->s3 and retrun if it is NULL immediately in ssl3_free before dereferencing it. Srinivas -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sun Nov 29 11:09:35 2015 From: rt at openssl.org (Trevor Larock via RT) Date: Sun, 29 Nov 2015 11:09:35 +0000 Subject: [openssl-dev] [openssl.org #4160] Candidate bug, malloc failure related issues in s3_enc.c, hm_pmeth.c In-Reply-To: References: Message-ID: Hi folks, Can I ask about malloc failure handling issues, seems affecting OpenSSL 1.0.1p and 1.0.2d, 1. In s3_enc.c::ssl3_digest_cached_records, we have the below code. s->s3->handshake_dgst = OPENSSL_malloc(SSL_MAX_DIGEST * sizeof(EVP_MD_CTX *)); memset(s->s3->handshake_dgst, 0, SSL_MAX_DIGEST * sizeof(EVP_MD_CTX *)); We are not checking for the return value of the malloc resulting in a straight null dereference in the memset. 2. In hm_pmeth.c::pkey_hmac_cleanup HMAC_PKEY_CTX *hctx = ctx->data; HMAC_CTX_cleanup(&hctx->ctx); Using hctx when it can be NULL. We could have failed to allocate ctx->data in int_ctx_new which calls pmeth->init (alloc can return error here). Thanks Trev -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From paul.dale at oracle.com Tue Nov 24 00:49:26 2015 From: paul.dale at oracle.com (Paul Dale) Date: Tue, 24 Nov 2015 10:49:26 +1000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151123231136.GA6451@kronk.local> References: <20151123015347.GJ18315@mournblade.imrryr.org> <3165858.AMXWLaS1CV@acid> <20151123231136.GA6451@kronk.local> Message-ID: <38138022.XYSrmVJakE@acid> On Mon, 23 Nov 2015 11:11:37 PM Alessandro Ghedini wrote: > Is this TLS connections? Yes, this is just measuring the TLS handshake. Renegotiations predominately. We deliberately didn't test the bulk symmetric crypto phase of the connection. > I'd like to know more... The data are a bit rough and ready but I've included what I can. I wasn't directly involved in taking these measurements, so Chinese whispers are entirely possible. I've been tasked with trying to find some performance enhancements. The TLS stack results are: stack CPU % connections/s OpenSSL 85 11,935 atomic patch 22 16,465 proof of concept only, the stack is broken elsewhere NSS 47 46,507 !!!!! ---------------------------------------------------------------------- The top ten bottlenecks identified by Sun Studio profiler. There are before my atomic change. Lock % 16 CPU % 41 +- EVP_MD_CTX_cleanup +- EVP_PKEY_CTX_free +- EVP_PKEY_free +- CRYPTO_add_lock +- locking_function +- pthread_mutex_lock Lock % 21 CPU % 50 +- EVP_MD_CTX_copy_ex +- EVP_PKEY_CTX_dup +- CRYPTO_add_lock +- locking_function +- pthread_mutex_lock Lock % 5 CPU % - +- EVP_PKEY_CTX_dup +- CRYPTO_add_lock +- locking_function +- pthread_mutex_lock Lock % 3 CPU % 3 +- EVP_PKEY_CTX_new +- CRYPTO_add_lock +- locking_function +- pthread_mutex_lock Lock % - CPU % 3 EVP_PKEY_free Lock % 2 CPU % 2 pkey_hmac_copy Lock % - CPU % 1 +- Connection::destroy() +- Connection::close() +- NZIO_Close +- nzos_Destroy_Ctx +- SSL_free +- ssl_cert_free +- ssl_cert_clear_certs Lock % - CPU % 2 +- ERR_clear_error +- ERR_get_state +- int_thread_get_item +- lh_retrieve Locl % - CPU % 1 X509_check_private_key Lock % - CPU % 1 sha1_block_data_order_ssse3 ---------------------------------------------------------------------- After making all CRYPTO_add calls atomic, which breaks things elsewhere in the TLS stack, we obtained the above performance improvement and these new bottlenecks -- take these with more of a grain of salt: Lock % 6 CPU % 13 SSL_new +- 46.000 (7%) nzos_Create_Ctx +- 38.530 (6%) SSL_new +- 35.370 (6%) CRYPTO_new_ex_data +- 35.310 (6%) int_new_ex_data +- 34.360 (5%) def_get_class +- 34.100 (5%) CRYPTO_lock +- 34.020 (5%) locking_function +- 32.620 (5%) pthread_mutex_lock Lock % 6 CPU % 12 SSL_SESSION_new +- 40.090 (6%) d2i_SSL_SESSION +- 34.420 (6%) SSL_SESSION_new +- 33.930 (5%) CRYPTO_new_ex_data +- 33.880 (5%) int_new_ex_data +- 32.630 (5%) def_get_class +- 32.390 (5%) CRYPTO_lock +- 32.370 (5%) locking_function +- 30.860 (5%) pthread_mutex_lock Lock % 9 CPU %22 BIO_new + BIO_new 1% + BIO_set 4% + CRYPTO_new_ex_data 5% + int_new_ex_data + def_get_class + CRYPTO_lock + locking_function + pthread_mutex_lock Lock % 11 CPU % 26 BIO_free +- BIO_free +- CRYPTO_free_ex_data +- int_free_ex_data +- def_get_class +- CRYPTO_lock +- locking_function +- pthread_mutex_lock Lock % 17 tls1_PRF +- tls1_PRF +- tls1_P_hash called from +- 62.400 (10%) ssl3_get_finished +- 62.120 (10%) ssl3_get_message +- 44.940 (7%) ssl3_read_bytes +- 28.530 (5%) ssl3_do_change_cipher_spec +- 23.410 (4%) tls1_final_finish_mac or +- 16.300 (3%) ssl3_take_mac +- 16.260 (3%) tls1_final_finish_mac or +- 17.430 (3%) ssl3_send_finished +- 15.240 (2%) tls1_final_finish_mac or +- 65.480 (10%) tls1_setup_key_block +- 62.890 (10%) tls1_generate_key_block Lock % 6 ERR_clear_error +- ERR_clear_error +- ERR_get_state +- int_thread_get_item +- lh_retrieve +- getrn CPU % 18.93 SSL_free CPU % 5.5 SSL_SESSION_free > As Matt mentioned, I'm curently working exactly on this. Would it be possible > for you to share your testing method and code? I'd like to verify that my > patches actually go in the right direction before having them merged (or maybe > you could do your tests on top of my patches, they should mostly work fine even > if the work is not complete yet, I think). I'm not sure I can share code and associated infrastructure at this point, we'd like to but we need approvals through the various internal channels. It might be possible for us to run these tests against your patches and mail you the results (less than ideal but probably workable), I'd have to ask the engineer who did this to see if they can justify the time involved. The bottom line is OpenSSL wants for finer grain locking, which the atomic operations provided. Having locks in the various contexts would achieve the same result and be less platform/compiler specific. For reference, my proof of concept atomic patch was: diff --git a/include/openssl/crypto.h b/include/openssl/crypto.h index 56afc51..803d7b7 100644 --- a/include/openssl/crypto.h +++ b/include/openssl/crypto.h @@ -220,8 +220,13 @@ extern "C" { CRYPTO_lock(CRYPTO_LOCK|CRYPTO_READ,type,__FILE__,__LINE__) # define CRYPTO_r_unlock(type) \ CRYPTO_lock(CRYPTO_UNLOCK|CRYPTO_READ,type,__FILE__,__LINE__) -# define CRYPTO_add(addr,amount,type) \ - CRYPTO_add_lock(addr,amount,type,__FILE__,__LINE__) +# if defined(__GNUC__) || defined(__INTEL_COMPILER) +# define CRYPTO_add(addr,amount,type) \ + __sync_add_and_fetch(addr, amount) +# else +# define CRYPTO_add(addr,amount,type) \ + CRYPTO_add_lock(addr,amount,type,__FILE__,__LINE__) +# endif # endif # else # define CRYPTO_w_lock(a) This should never be applied, it breaks things and is quick and ugly. Regards, Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sun Nov 29 13:28:34 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Sun, 29 Nov 2015 13:28:34 +0000 Subject: [openssl-dev] [openssl.org #4159] BUG ::: Null dereference in ssl3_free In-Reply-To: <20151129132824.GA12217@roeckx.be> References: <20151129132824.GA12217@roeckx.be> Message-ID: On Sun, Nov 29, 2015 at 11:09:34AM +0000, Srinivas Koripella via RT wrote: > Description. > > We are dereferencing s->s3 in ssl3_free without checking if s->s3 is null or not. This has already been fixed in the current git versions. I'm wondering why you see this, you should only get this in case malloc() failed. Kurt From rt at openssl.org Sun Nov 29 22:39:01 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Sun, 29 Nov 2015 22:39:01 +0000 Subject: [openssl-dev] [openssl.org #4160] Candidate bug, malloc failure related issues in s3_enc.c, hm_pmeth.c In-Reply-To: <20151129223848.GA1651@roeckx.be> References: <20151129223848.GA1651@roeckx.be> Message-ID: On Sun, Nov 29, 2015 at 11:09:35AM +0000, Trevor Larock via RT wrote: > Hi folks, > > Can I ask about malloc failure handling issues, seems affecting OpenSSL 1.0.1p and 1.0.2d, > > 1. In s3_enc.c::ssl3_digest_cached_records, we have the below code. > > s->s3->handshake_dgst = > OPENSSL_malloc(SSL_MAX_DIGEST * sizeof(EVP_MD_CTX *)); > memset(s->s3->handshake_dgst, 0, SSL_MAX_DIGEST * sizeof(EVP_MD_CTX *)); > > We are not checking for the return value of the malloc resulting in a straight null dereference in the memset. That seems to be fixed in the master branch. > 2. In hm_pmeth.c::pkey_hmac_cleanup > > HMAC_PKEY_CTX *hctx = ctx->data; > HMAC_CTX_cleanup(&hctx->ctx); > > Using hctx when it can be NULL. We could have failed to allocate ctx->data in int_ctx_new which calls pmeth->init (alloc can return error here). So when pmeth->init() fails it calls EVP_PKEY_CTX_free(), which calls ctx->pmeth->cleanup(). I'm guessing there are other cleanup / free functions that don't really expect to get called when init / new failed. At least ossl_hmac_cleanup() looks to have the same problem, while things like pkey_ec_cleanup(), pkey_dh_cleanup() and pkey_rsa_cleanup() look good. Kurt From rt at openssl.org Mon Nov 30 01:17:58 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Mon, 30 Nov 2015 01:17:58 +0000 Subject: [openssl-dev] [openssl.org #4158] GOST 2012 compatibility is broken by commit 28f4580c1e510ccf4278a20975c9bc3306f758d6 In-Reply-To: References: Message-ID: On Sun Nov 29 09:04:03 2015, beldmit at gmail.com wrote: > Hello OpenSSL Team, > > I found out that the commit 28f4580c1e510ccf4278a20975c9bc3306f758d6 breaks > GOST 2012 client auth processing. > This should be fixed by commit aa430c7467bcb7aa0a88 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Mon Nov 30 03:46:17 2015 From: rt at openssl.org (Srinivas Koripella via RT) Date: Mon, 30 Nov 2015 03:46:17 +0000 Subject: [openssl-dev] [openssl.org #4159] BUG ::: Null dereference in ssl3_free In-Reply-To: References: <20151129132824.GA12217@roeckx.be> Message-ID: Yes. Malloc failed in our case. Srinivas -----Original Message----- From: Kurt Roeckx via RT [mailto:rt at openssl.org] Sent: Sunday, November 29, 2015 6:59 PM To: Srinivas Koripella Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4159] BUG ::: Null dereference in ssl3_free On Sun, Nov 29, 2015 at 11:09:34AM +0000, Srinivas Koripella via RT wrote: > Description. > > We are dereferencing s->s3 in ssl3_free without checking if s->s3 is null or not. This has already been fixed in the current git versions. I'm wondering why you see this, you should only get this in case malloc() failed. Kurt From beldmit at gmail.com Mon Nov 30 06:07:36 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 30 Nov 2015 09:07:36 +0300 Subject: [openssl-dev] [openssl.org #4158] GOST 2012 compatibility is broken by commit 28f4580c1e510ccf4278a20975c9bc3306f758d6 In-Reply-To: References: Message-ID: Dear Stephen, On Mon, Nov 30, 2015 at 4:17 AM, Stephen Henson via RT wrote: > On Sun Nov 29 09:04:03 2015, beldmit at gmail.com wrote: > > Hello OpenSSL Team, > > > > I found out that the commit 28f4580c1e510ccf4278a20975c9bc3306f758d6 > breaks > > GOST 2012 client auth processing. > > > > This should be fixed by commit aa430c7467bcb7aa0a88 > It works. Thank you very much! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Nov 30 06:07:47 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Mon, 30 Nov 2015 06:07:47 +0000 Subject: [openssl-dev] [openssl.org #4158] GOST 2012 compatibility is broken by commit 28f4580c1e510ccf4278a20975c9bc3306f758d6 In-Reply-To: References: Message-ID: Dear Stephen, On Mon, Nov 30, 2015 at 4:17 AM, Stephen Henson via RT wrote: > On Sun Nov 29 09:04:03 2015, beldmit at gmail.com wrote: > > Hello OpenSSL Team, > > > > I found out that the commit 28f4580c1e510ccf4278a20975c9bc3306f758d6 > breaks > > GOST 2012 client auth processing. > > > > This should be fixed by commit aa430c7467bcb7aa0a88 > It works. Thank you very much! -- SY, Dmitry Belyavsky From hkario at redhat.com Mon Nov 30 14:38:13 2015 From: hkario at redhat.com (Hubert Kario) Date: Mon, 30 Nov 2015 15:38:13 +0100 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <38138022.XYSrmVJakE@acid> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123231136.GA6451@kronk.local> <38138022.XYSrmVJakE@acid> Message-ID: <1505607.eacbI7ABhB@pintsize.usersys.redhat.com> On Tuesday 24 November 2015 10:49:26 Paul Dale wrote: > On Mon, 23 Nov 2015 11:11:37 PM Alessandro Ghedini wrote: > > Is this TLS connections? > > Yes, this is just measuring the TLS handshake. Renegotiations > predominately. We deliberately didn't test the bulk symmetric crypto > phase of the connection. > > I'd like to know more... > > The data are a bit rough and ready but I've included what I can. I > wasn't directly involved in taking these measurements, so Chinese > whispers are entirely possible. I've been tasked with trying to find > some performance enhancements. > > The TLS stack results are: > > stack CPU % connections/s > OpenSSL 85 11,935 > atomic patch 22 16,465 proof of concept only, the stack > is broken elsewhere > NSS 47 46,507 !!!!! are you sure that the negotiated cipher suite is the same and that the NSS is not configured to reuse the server key share if you're using DHE or ECDHE? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rt at openssl.org Mon Nov 30 14:39:25 2015 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 30 Nov 2015 14:39:25 +0000 Subject: [openssl-dev] [openssl.org #4157] Download Documentation In-Reply-To: References: Message-ID: Did you see the INSTALL and README files in whatever version you downloaded? On the download page, I added a link to the release strategy which explains the release numbering. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Nov 30 15:25:01 2015 From: rt at openssl.org (Prashant Dhange via RT) Date: Mon, 30 Nov 2015 15:25:01 +0000 Subject: [openssl-dev] [openssl.org #4161] Bug : aes-128-ccm cipher mode not working In-Reply-To: References: Message-ID: Hi, We are trying to generate CMAC authentication code using EVP_aes_128_ccm mode. The CMAC_Final function returning the single byte hash code which suppose to return 16-byte hash code. We tried same algorithm with EVP_aes_128_cbc mode which is returning 16-byte hash code but we have specific requirement for EVP_aes_128_ccm mode. Here is the sample code snippet for CMAC generation: {{{ ctx = CMAC_CTX_new(); CMAC_Init(ctx, key, key_len, EVP_aes_128_ccm(), NULL); CMAC_Update(ctx, d, n); CMAC_Final(ctx, md, &md_len); CMAC_CTX_free(ctx); }}} Kindly provide us inputs on this issue. Thanks, ~Prashant. -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From matt at openssl.org Mon Nov 30 15:38:12 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 30 Nov 2015 15:38:12 +0000 Subject: [openssl-dev] Forthcoming OpenSSL releases Message-ID: <565C6D64.8010003@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Forthcoming OpenSSL releases ============================ The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2e, 1.0.1q, 1.0.0t and 0.9.8zh. These releases will be made available on 3rd December between approx. 1pm and 5pm (UTC). They will fix a number of security defects, the highest of which is classified as "moderate" severity. Please note that the OpenSSL project has recently revised its severity definitions by introducing a new "critical" level, i.e. the severity levels are now: critical, high, moderate and low. Please see the following page for further details: https://www.openssl.org/policies/secpolicy.html Please also note that, as per our previous announcements, the 1.0.0 and 0.9.8 releases will no longer be receiving security updates after the end of this year. This means that, barring any unexpected significant security issues between now and 31st December 2015, it is likely that these releases will be the last ones for 1.0.0 and 0.9.8. Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWXG1kAAoJENnE0m0OYESR3vgH/0R7GCsN4moof7ezQIbZbxxN qeiwH2SGj0a5KXM/J9Ee4jcQWA2n0SfUeFbgLSvqBO8BQdz3oTJMF45Z+gXjWFqZ OiEQ+ZFayNm/Tb46OFhglbRBhfb7Je4sy4i8cSW6wGQ2EdWz3JN/xWC0q9KMqQpi k8IwitBK3WxZ/Je+rHZvsDzABWd3Jf2+QlDjwHXxSfrW9UBc5Wr7e+d5XMQk2KML FGJtkucAFs+AiOWvfsJ2WzFYy373M7pYQT38ODOuvT9HxMHzDY89kj2BsFjr8pZY yIk9fAE1BTKRoNoUPETVuYi0Wq+xFHgV5urFQztxglWymcxAILHOZ+PZDyT/m5Q= =QGvN -----END PGP SIGNATURE----- From hkario at redhat.com Mon Nov 30 16:10:52 2015 From: hkario at redhat.com (Hubert Kario) Date: Mon, 30 Nov 2015 17:10:52 +0100 Subject: [openssl-dev] [openssl.org #4157] Download Documentation In-Reply-To: References: Message-ID: <4278203.EzjrOVC3Ah@pintsize.usersys.redhat.com> On Friday 27 November 2015 13:39:36 Tom Jay via RT wrote: > 3. Some kind of useful examples of common usages > of OpenSSL would be appreciated. I'm still trawling through the > documentation trying to figure out how to do what I want to do and am > relying heaving on 3rd party guides to figure out what I want to do. https://wiki.openssl.org/index.php/Main_Page If you have specific use cases missing from there, please tell, but be precise -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rt at openssl.org Mon Nov 30 16:10:58 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Mon, 30 Nov 2015 16:10:58 +0000 Subject: [openssl-dev] [openssl.org #4157] Download Documentation In-Reply-To: <4278203.EzjrOVC3Ah@pintsize.usersys.redhat.com> References: <4278203.EzjrOVC3Ah@pintsize.usersys.redhat.com> Message-ID: On Friday 27 November 2015 13:39:36 Tom Jay via RT wrote: > 3. Some kind of useful examples of common usages > of OpenSSL would be appreciated. I'm still trawling through the > documentation trying to figure out how to do what I want to do and am > relying heaving on 3rd party guides to figure out what I want to do. https://wiki.openssl.org/index.php/Main_Page If you have specific use cases missing from there, please tell, but be precise -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From uri at ll.mit.edu Mon Nov 30 16:23:48 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 30 Nov 2015 16:23:48 +0000 Subject: [openssl-dev] [openssl.org #4157] Download Documentation In-Reply-To: <4278203.EzjrOVC3Ah@pintsize.usersys.redhat.com> References: <4278203.EzjrOVC3Ah@pintsize.usersys.redhat.com> Message-ID: On 11/30/15, 11:10 , "openssl-dev on behalf of Hubert Kario" wrote: >On Friday 27 November 2015 13:39:36 Tom Jay via RT wrote: >> 3. Some kind of useful examples of common usages >> of OpenSSL would be appreciated. > >https://wiki.openssl.org/index.php/Main_Page > >If you have specific use cases missing from there, please tell, but be >precise It talks only about *programming*, using OpenSSL toolkit as a *library* to link against (and about ways to extend that library). I think it omits a *huge* area of use cases where ?openssl? executable itself is used to (a) test and/or debug other SSL/TLS applications and packages, (b) perform cryptographic processing on files and data - either standalone, or as a part of a script (shell or such). -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From rsalz at akamai.com Mon Nov 30 16:28:06 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 30 Nov 2015 16:28:06 +0000 Subject: [openssl-dev] Download Documentation Message-ID: <54c2ad4815b94cfb97fc9a530ab1bd8b@usma1ex-dag1mb1.msg.corp.akamai.com> > I think it omits a *huge* area of use cases where ?openssl? executable itself is used to (a) test and/or debug other SSL/TLS applications and packages, (b) perform cryptographic processing on files and data - either standalone, or as a part of a script (shell or such). It would be great if people doing those kinds of things could post information about it. The community is in a better position to help here, not the development team. From rt at openssl.org Mon Nov 30 16:38:54 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Mon, 30 Nov 2015 16:38:54 +0000 Subject: [openssl-dev] [openssl.org #4161] Bug : aes-128-ccm cipher mode not working In-Reply-To: References: Message-ID: On Mon Nov 30 15:25:01 2015, prashantd at ryussi.com wrote: > Hi, > > We are trying to generate CMAC authentication code using EVP_aes_128_ccm > mode. The CMAC_Final function returning the single byte hash code which > suppose to return 16-byte hash code. > > We tried same algorithm with EVP_aes_128_cbc mode which is returning > 16-byte hash code but we have specific requirement for EVP_aes_128_ccm mode. > CCM mode is not compatible with CMAC. It doesn't make a lot of sense because CCM mode has a MAC built in. To use that you need to set up the cipher correctly. See the documentation, demos/evp/aesccm.c and the wiki for more details. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From nico at cryptonector.com Mon Nov 30 17:12:24 2015 From: nico at cryptonector.com (Nico Williams) Date: Mon, 30 Nov 2015 11:12:24 -0600 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <20151123235654.GY18315@mournblade.imrryr.org> References: <20151123015347.GJ18315@mournblade.imrryr.org> <20151123054139.GB11308@localhost> <3165858.AMXWLaS1CV@acid> <565390B3.2030200@openssl.org> <20151123232817.GD9363@localhost> <20151123235654.GY18315@mournblade.imrryr.org> Message-ID: <20151130171223.GG12304@localhost> On Mon, Nov 23, 2015 at 11:56:54PM +0000, Viktor Dukhovni wrote: > > It may be a good idea to rethink locking completely. > > There is some glimmer of hope in that as various libcrypto structures > become opaque, the locking moves from application code into the > library. For example, we now have (yet to be documented): > > X509_up_ref() Ideally there would be very little locking in OpenSSL, and instead the app would be responsible for most locking (if needed). But that will be a lengthy transition, no? Maybe we'll need functions by which to indicate that the app will be doing locking for specific objects. Still, functions like RAND_bytes() that have no context object will need locking, so new functions will be needed that take contexts so as to minimize locking. > Doing this requires a global review of the API, and filling in > missing functions and documentation. :-( Yes. Nico -- From rt at openssl.org Mon Nov 30 17:36:34 2015 From: rt at openssl.org (Jeremy Farrell via RT) Date: Mon, 30 Nov 2015 17:36:34 +0000 Subject: [openssl-dev] EXT :Re: [openssl.org #3931] OpenSSL 1.0.2(c, d) hangs on Sun T3 in OPENSSL_cpuid_setup() In-Reply-To: <565C8916.7000805@oracle.com> References: <565C8916.7000805@oracle.com> Message-ID: On Mon Jul 20 13:03:05 UTC 2015 Andy Polyakov wrote: > >> I applied the patch you sent and configured/compiled using >> "solaris-sparcv9-gcc" and the program completes normally. >> As I am unable to use patched/unofficial code for our operational ... > >What is criteria for being "official"? Explicitly released as tar-ball >or just commit to repository? Unless I'm missing it, this patch doesn't appear to have been committed to the repository yet. Any chance you could get this into 1.0.2e? Regards, jjf -- J. J. Farrell From rt at openssl.org Mon Nov 30 17:57:01 2015 From: rt at openssl.org (Puckett, Rick via RT) Date: Mon, 30 Nov 2015 17:57:01 +0000 Subject: [openssl-dev] EXT :Re: [openssl.org #3931] OpenSSL 1.0.2(c, d) hangs on Sun T3 in OPENSSL_cpuid_setup() In-Reply-To: References: <565C8916.7000805@oracle.com> Message-ID: Jeremy, Are you asking me? I don't have commit access to the repository. Obviously, I would endorse adding this patch as we have Sun T-3 systems. :-) As the patch wasn't incorporated into an official release, I worked around this issue by using the configure parameter "solaris-sparcv7". - Rick -----Original Message----- From: Jeremy Farrell via RT [mailto:rt at openssl.org] Sent: Monday, November 30, 2015 12:37 PM To: Puckett, Rick (IS) Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] EXT :Re: [openssl.org #3931] OpenSSL 1.0.2(c, d) hangs on Sun T3 in OPENSSL_cpuid_setup() On Mon Jul 20 13:03:05 UTC 2015 Andy Polyakov wrote: > >> I applied the patch you sent and configured/compiled using >> "solaris-sparcv9-gcc" and the program completes normally. >> As I am unable to use patched/unofficial code for our operational ... > >What is criteria for being "official"? Explicitly released as tar-ball >or just commit to repository? Unless I'm missing it, this patch doesn't appear to have been committed to the repository yet. Any chance you could get this into 1.0.2e? Regards, jjf -- J. J. Farrell From rt at openssl.org Mon Nov 30 18:00:55 2015 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 30 Nov 2015 18:00:55 +0000 Subject: [openssl-dev] [openssl.org #4161] Bug : aes-128-ccm cipher mode not working In-Reply-To: References: Message-ID: Wrong crypto being used, not an OpenSSL error. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Nov 30 18:32:00 2015 From: rt at openssl.org (Jeremy Farrell via RT) Date: Mon, 30 Nov 2015 18:32:00 +0000 Subject: [openssl-dev] EXT :Re: [openssl.org #3931] OpenSSL 1.0.2(c, d) hangs on Sun T3 in OPENSSL_cpuid_setup() In-Reply-To: <565C920D.8030207@oracle.com> References: <565C8916.7000805@oracle.com> <565C920D.8030207@oracle.com> Message-ID: Sorry Rick, no, I was asking openssl-dev. I sent the email solely to rt at openssl.org as recommended on the web site, and it looks like it rewrote it 'To' you and 'Cc' to openssl-dev. Sorry for the confusion. Regards, jjf On 30/11/2015 17:57, Puckett, Rick via RT wrote: > Jeremy, > > Are you asking me? I don't have commit access to the repository. > Obviously, I would endorse adding this patch as we have Sun T-3 > systems. :-) As the patch wasn't incorporated into an official > release, I worked around this issue by using the configure parameter > "solaris-sparcv7". > > - Rick > > -----Original Message----- >From: Jeremy Farrell via RT [mailto:rt at openssl.org] >To: Puckett, Rick (IS) >Cc: openssl-dev at openssl.org > > On Mon Jul 20 13:03:05 UTC 2015 Andy Polyakov wrote: >> >>> I applied the patch you sent and configured/compiled using >> >>> "solaris-sparcv9-gcc" and the program completes normally. As I am >>> unable to use patched/unofficial code for our operational ... >> >> What is criteria for being "official"? Explicitly released as >> tar-ball >or just commit to repository? > > Unless I'm missing it, this patch doesn't appear to have been > committed to the repository yet. Any chance you could get this into > 1.0.2e? -- J. J. Farrell From rt at openssl.org Mon Nov 30 18:37:02 2015 From: rt at openssl.org (Leonidas Da Silva Barbosa via RT) Date: Mon, 30 Nov 2015 18:37:02 +0000 Subject: [openssl-dev] [openssl.org #4162] [PATCH] Removing vrsave load and store In-Reply-To: <20151130181406.GA14203@bluepex.com> References: <20151130181406.GA14203@bluepex.com> Message-ID: Access to VRSAVE have a high cost in performance. Since ABI was update we don't need to save what vector register we are using. Removing VRSAVE access can improve a bit more our performance. Signed-off-by: Leonidas S. Barbosa Signed-off-by: Paulo Flabiano Smorigo --- crypto/aes/asm/aesp8-ppc.pl | 20 -------------------- crypto/modes/asm/ghashp8-ppc.pl | 11 ----------- 2 files changed, 31 deletions(-) diff --git a/crypto/aes/asm/aesp8-ppc.pl b/crypto/aes/asm/aesp8-ppc.pl index a1891cc..35f36ef 100755 --- a/crypto/aes/asm/aesp8-ppc.pl +++ b/crypto/aes/asm/aesp8-ppc.pl @@ -104,10 +104,6 @@ Lset_encrypt_key: andi. r0,$bits,0x3f bne- Lenc_key_abort - lis r0,0xfff0 - mfspr $vrsave,256 - mtspr 256,r0 - bl Lconsts mtlr r11 @@ -336,7 +332,6 @@ Ldone: vsel $in1,$outhead,$in1,$outmask stvx $in1,0,$inp li $ptr,0 - mtspr 256,$vrsave stw $rounds,0($out) Lenc_key_abort: @@ -408,10 +403,7 @@ $code.=<<___; .align 5 .${prefix}_${dir}crypt: lwz $rounds,240($key) - lis r0,0xfc00 - mfspr $vrsave,256 li $idx,15 # 15 is not typo - mtspr 256,r0 lvx v0,0,$inp neg r11,$out @@ -465,7 +457,6 @@ Loop_${dir}c: vsel v0,v0,v4,v2 stvx v0,$idx,$out - mtspr 256,$vrsave blr .long 0 .byte 0,12,0x14,0,0,0,3,0 @@ -490,9 +481,6 @@ $code.=<<___; bltlr- cmpwi $enc,0 # test direction - lis r0,0xffe0 - mfspr $vrsave,256 - mtspr 256,r0 li $idx,15 vxor $rndkey0,$rndkey0,$rndkey0 @@ -638,7 +626,6 @@ Lcbc_done: vsel $inout,$ivec,$inptail,$outmask stvx $inout,$idx,$ivp - mtspr 256,$vrsave blr .long 0 .byte 0,12,0x14,0,0,0,6,0 @@ -1196,7 +1183,6 @@ Lcbc_dec8x_done: stvx $inpperm,r11,$sp addi r11,r11,32 - mtspr 256,$vrsave lvx v20,r10,$sp # ABI says so addi r10,r10,32 lvx v21,r11,$sp @@ -1249,10 +1235,6 @@ $code.=<<___; ${UCMP}i $len,1 bltlr- - lis r0,0xfff0 - mfspr $vrsave,256 - mtspr 256,r0 - li $idx,15 vxor $rndkey0,$rndkey0,$rndkey0 le?vspltisb $tmp,0x0f @@ -1344,7 +1326,6 @@ Loop_ctr32_enc: vsel $inout,$outhead,$inout,$outmask stvx $inout,0,$out - mtspr 256,$vrsave blr .long 0 .byte 0,12,0x14,0,0,0,6,0 @@ -1849,7 +1830,6 @@ Lctr32_enc8x_done: stvx $inpperm,r11,$sp addi r11,r11,32 - mtspr 256,$vrsave lvx v20,r10,$sp # ABI says so addi r10,r10,32 lvx v21,r11,$sp diff --git a/crypto/modes/asm/ghashp8-ppc.pl b/crypto/modes/asm/ghashp8-ppc.pl index e76a58c..63e46fa 100755 --- a/crypto/modes/asm/ghashp8-ppc.pl +++ b/crypto/modes/asm/ghashp8-ppc.pl @@ -46,7 +46,6 @@ my ($Xip,$Htbl,$inp,$len)=map("r$_",(3..6)); # argument block my ($Xl,$Xm,$Xh,$IN)=map("v$_",(0..3)); my ($zero,$t0,$t1,$t2,$xC2,$H,$Hh,$Hl,$lemask)=map("v$_",(4..12)); -my $vrsave="r12"; $code=<<___; .machine "any" @@ -56,11 +55,8 @@ $code=<<___; .globl .gcm_init_p8 .align 5 .gcm_init_p8: - lis r0,0xfff0 li r8,0x10 - mfspr $vrsave,256 li r9,0x20 - mtspr 256,r0 li r10,0x30 lvx_u $H,0,r4 # load H @@ -90,7 +86,6 @@ $code=<<___; stvx_u $H, r9,r3 stvx_u $Hh,r10,r3 - mtspr 256,$vrsave blr .long 0 .byte 0,12,0x14,0,0,0,2,0 @@ -102,9 +97,7 @@ $code=<<___; .gcm_gmult_p8: lis r0,0xfff8 li r8,0x10 - mfspr $vrsave,256 li r9,0x20 - mtspr 256,r0 li r10,0x30 lvx_u $IN,0,$Xip # load Xi @@ -140,7 +133,6 @@ $code=<<___; le?vperm $Xl,$Xl,$Xl,$lemask stvx_u $Xl,0,$Xip # write out Xi - mtspr 256,$vrsave blr .long 0 .byte 0,12,0x14,0,0,0,2,0 @@ -152,9 +144,7 @@ $code=<<___; .gcm_ghash_p8: lis r0,0xfff8 li r8,0x10 - mfspr $vrsave,256 li r9,0x20 - mtspr 256,r0 li r10,0x30 lvx_u $Xl,0,$Xip # load Xi @@ -209,7 +199,6 @@ Loop: le?vperm $Xl,$Xl,$Xl,$lemask stvx_u $Xl,0,$Xip # write out Xi - mtspr 256,$vrsave blr .long 0 .byte 0,12,0x14,0,0,0,4,0 -- 2.5.0 _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Nov 30 18:44:30 2015 From: rt at openssl.org (Kaduk, Ben via RT) Date: Mon, 30 Nov 2015 18:44:30 +0000 Subject: [openssl-dev] [openssl.org #4155] In function int_thread_del_item, when hash == int_thread_hash, one is passed to free and the other is used in a comparison In-Reply-To: <565C990B.8070004@akamai.com> References: <565C990B.8070004@akamai.com> Message-ID: On 11/24/2015 05:06 AM, Pascal Cuoq via RT wrote: > This issue is similar in nature to 4151 (http://www.mail-archive.com/openssl-dev at openssl.org/msg40950.html ): it is about a dangling pointer being used, but not used for dereferencing, so it's not a memory error. The dangling pointer is used in a comparison. > > The function int_thread_del_item can reach the point were it calls ?lh_ERR_STATE_free(int_thread_hash);? with hash == int_thread_hash. That attached patch prints a message like ?hash == int_thread_hash == 0xb2a6d0? when this happens. Just after the call to lh_ERR_STATE_free, both hash and int_thread_hash contain dangling pointers. The variable int_thread_hash is immediately set to NULL. > > The problem that I am reporting is that just afterwards, &hash is passed to the function int_thread_release: > > https://github.com/openssl/openssl/blob/079a1a9014b89661f0a612a5a9724ad9c77f21a3/crypto/err/err.c#L412 > > Note that per J.2 of C99 (n1256.pdf page 503, document-internal numbering), using the value of a pointer that refers to space deallocated by a call to free is undefined behavior, even for just comparison. (This is covered in passing at http://web.torek.net/torek/c/numbers2.html) -Ben From rt at openssl.org Mon Nov 30 20:12:58 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Mon, 30 Nov 2015 20:12:58 +0000 Subject: [openssl-dev] [openssl.org #4155] In function int_thread_del_item, when hash == int_thread_hash, one is passed to free and the other is used in a comparison In-Reply-To: <20151130201253.GA22084@roeckx.be> References: <20151130201253.GA22084@roeckx.be> Message-ID: On Tue, Nov 24, 2015 at 11:06:44AM +0000, Pascal Cuoq via RT wrote: > This issue is similar in nature to 4151 (http://www.mail-archive.com/openssl-dev at openssl.org/msg40950.html ): it is about a dangling pointer being used, but not used for dereferencing, so it's not a memory error. The dangling pointer is used in a comparison. > > The function int_thread_del_item can reach the point were it calls "lh_ERR_STATE_free(int_thread_hash);" with hash == int_thread_hash. That attached patch prints a message like "hash == int_thread_hash == 0xb2a6d0" when this happens. Just after the call to lh_ERR_STATE_free, both hash and int_thread_hash contain dangling pointers. The variable int_thread_hash is immediately set to NULL. > > The problem that I am reporting is that just afterwards, &hash is passed to the function int_thread_release: > > https://github.com/openssl/openssl/blob/079a1a9014b89661f0a612a5a9724ad9c77f21a3/crypto/err/err.c#L412 > > In that function, the argument "hash" points to the local variable "hash" of int_thread_del_item (which contains a dangling pointer). > Thus the comparison "*hash == NULL" involves a dangling pointer: I thinkt he following untested patch should fix that: --- a/crypto/err/err.c +++ b/crypto/err/err.c @@ -403,8 +403,10 @@ static void int_thread_del_item(const ERR_STATE *d) if (int_thread_hash_references == 1 && int_thread_hash && lh_ERR_STATE_num_items(int_thread_hash) == 0) { + int_thread_hash_references = 0; lh_ERR_STATE_free(int_thread_hash); int_thread_hash = NULL; + hash = NULL; } } CRYPTO_w_unlock(CRYPTO_LOCK_ERR); Kurt From cpservicespb at gmail.com Mon Nov 30 21:24:35 2015 From: cpservicespb at gmail.com (CpServiceSPb .) Date: Tue, 1 Dec 2015 00:24:35 +0300 Subject: [openssl-dev] OpenSSL as OCSP server (responder) as multithreading daemon ! Message-ID: > We have no plans to do this. >> May be will put it into your plans ? >>> Doubtful. We have lots of other work to do. Writing a full-strength database-backed OCSP responder is outside of our interests. I decided not wait for you and I have made OSSL Ocsp responder based at index DB - storing/getting some necessary parameters for its operating at Index text DB in my own. Now is for 1.0.2d version. Look at: https://github.com/CpServiceSpb/OpenSSLOcsp.git And a big wishing to you as dev. team is to check code and include to the next nearest release version. Because I need Windows version also, but man, who builds (compiles) OSSL installation for Windows make it for released main versions only (not for forked) . And I don' t have Windows building environment for it at the time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Nov 30 21:26:27 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 30 Nov 2015 21:26:27 +0000 Subject: [openssl-dev] OpenSSL as OCSP server (responder) as multithreading daemon ! In-Reply-To: References: Message-ID: Congratulations, sounds like nice work! ? And a big wishing to you as dev. team is to check code and include to the next nearest release version. I doubt anyone on the team will review the code, and it almost certainly will not become part of OpenSSL. I hope that others are interested and will contribute to your project. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cpservicespb at gmail.com Mon Nov 30 22:02:51 2015 From: cpservicespb at gmail.com (CpServiceSPb .) Date: Tue, 1 Dec 2015 01:02:51 +0300 Subject: [openssl-dev] OpenSSL as OCSP server (responder) as multithreading daemon ! Message-ID: > ... and it almost certainly will not become part of OpenSSL It sound bad. Why this part of code will never become part of OSSL ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Nov 30 22:05:30 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 30 Nov 2015 22:05:30 +0000 Subject: [openssl-dev] OpenSSL as OCSP server (responder) as multithreading daemon ! In-Reply-To: References: Message-ID: ? Why this part of code will never become part of OSSL ? It's not what we do. OpenSSL is a crypto and TLS toolkit. It is not a general PKI solution. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cpservicespb at gmail.com Mon Nov 30 22:34:53 2015 From: cpservicespb at gmail.com (CpServiceSPb .) Date: Tue, 1 Dec 2015 01:34:53 +0300 Subject: [openssl-dev] OpenSSL as OCSP server (responder) as multithreading daemon ! Message-ID: Nevertheless, OSSL has Ocsp with responder feature. Why could not to extend functionality ? And in the future to come to almost full Certificate Authority center as a fullforce solution along one line with other Linux and even MS AD CS sokutions. Moreover, I think, many people need it and will be glad to get it within OSSL released versions that will make OSSL more popular. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Nov 30 22:40:30 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 30 Nov 2015 22:40:30 +0000 Subject: [openssl-dev] OpenSSL as OCSP server (responder) as multithreading daemon ! In-Reply-To: References: Message-ID: <1e8e517a258145c9943188f603623585@usma1ex-dag1mb1.msg.corp.akamai.com> ? Why could not to extend functionality ? Because there are other things we are working on (see the roadmap at http://openssl.org/policies/roadmap.html ) ? And in the future to come to almost full Certificate Authority center as a fullforce solution along one line with other Linux and even MS AD CS sokutions. ? Moreover, I think, many people need it and will be glad to get it within OSSL released versions that will make OSSL more popular. Sure. But they do not have to be part of OpenSSL. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Mon Nov 30 23:21:34 2015 From: paul.dale at oracle.com (Paul Dale) Date: Tue, 01 Dec 2015 09:21:34 +1000 Subject: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread In-Reply-To: <1505607.eacbI7ABhB@pintsize.usersys.redhat.com> References: <20151123015347.GJ18315@mournblade.imrryr.org> <38138022.XYSrmVJakE@acid> <1505607.eacbI7ABhB@pintsize.usersys.redhat.com> Message-ID: <2393198.BXy04kfg64@acid> > are you sure that the negotiated cipher suite is the same and that the > NSS is not configured to reuse the server key share if you're using DHE > or ECDHE? The cipher suite was the same. I'd have to check to see exactly which was used. It is certainly possible that NSS was configured as you suggest and, if so, this would improve its performance. However, the obstacle preventing 100% CPU utilisation for both stacks is lock contention. The NSS folks apparently spent a lot of effort addressing this and they have a far more scalable locking model than OpenSSL: one lock per context for all the different kinds of context versus a small number of global locks. There is definitely scope for improvement here. My atomic operation suggestion is one approach which was quick and easy to validate, better might be more locks since it doesn't introduce a new paradigm and is more widely supported (C11 notwithstanding). Regards, Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: