Re: [openssl-dev] [openssl-master 0/1] AFALG: Support AES GCM
Please open a GitHub PR; posts to the mailing list won’t make it in. BTW, the “iov” struct isn’t portable. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c
* The current patch ( PR 5164 ) just changes "can be safely used" to "can generally be used safely". Without enough information for a user of the library to know whether a given usage is safe, this isn't useful documentation. When it comes to threading, "generally safe" is the same as "unsafe". There needs to be at least a little bit of guidance. Pedantically and strictly speaking, you might be correct. Pragmatically, however, many people have been able to write or deploy multi-threaded servers. I doubt that anyone on the project will do anything approaching a definitive thread-safety analysis, let alone documentation. Even with the “small number of API’s” that might be affected. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c
* Well, the most likely fix is to make the “safely” wording be more vague, which I doubt you’ll like. But I doubt anyone on the team has much interest in fixing 1.0.2 locking issues. https://github.com/openssl/openssl/pull/5164 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c
* OpenSSL should provide API to retrieve extension by OID. Yes! Can you open a github issue for that? -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c
Create the OID at your program startup and store the NID in a global variable. From: Yun Jiang <yun.ji...@realvnc.com> Reply-To: openssl-dev <openssl-dev@openssl.org> Date: Wednesday, January 24, 2018 at 7:38 AM To: openssl-dev <openssl-dev@openssl.org> Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c Thanks! The problem is that I need to get a customized certificate extension based on an OID. Until now, I cannot find a solution without dynamically calling OBJ_create(OID, NULL. NULL). Yun From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Peter Waltenberg Sent: 24 January 2018 01:23 To: Salz, Rich <rs...@akamai.com>; openssl-dev@openssl.org Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c It's also not that much of a problem in practice.. If you are using those API's you are adding new crypto. methods. Doing that after threading has started is not going to give good results with or without locking. Peter From: "Salz, Rich via openssl-dev" <openssl-dev@openssl.org<mailto:openssl-dev@openssl.org>> To:"openssl-dev@openssl.org<mailto:openssl-dev@openssl.org>" <openssl-dev@openssl.org<mailto:openssl-dev@openssl.org>> Date:24/01/2018 11:19 Subject:Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c Sent by:"openssl-dev" <openssl-dev-boun...@openssl.org<mailto:openssl-dev-boun...@openssl.org>> * OpenSSL APIs, which makes the following OpenSSL documentation statement invalid (https://www.openssl.org/docs/man1.0.2/crypto/threads.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.0.2_crypto_threads.html=DwMFAw=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=ZS_kRxGa4vj0O6wqfY-6q7kwVT0WiIMkFqw1XWHym4o=GK3QtuXP-8j_1nbRihxeJGLAIYXt1BNIyh3WHP6EJlY=>) * "OpenSSL can safely be used in multi-threaded applications provided that at least two callback functions are set, locking_function and threadid_func." * Is there any planning to fix this issue? Well, the most likely fix is to make the “safely” wording be more vague, which I doubt you’ll like. But I doubt anyone on the team has much interest in fixing 1.0.2 locking issues.-- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY=xEO93f-eFk98ZtSS2VW5oQoqCSoxBFAun8n0dZayTrs=9NZPKi5lqIGH6Jq4RqlHOiKqzuqUqZQMEQvpBr3aKsw= -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c
On 01/23/2018 07:19 PM, Salz, Rich via openssl-dev wrote: > > * OpenSSL APIs, which makes the following OpenSSL documentation > statement invalid > (https://www.openssl.org/docs/man1.0.2/crypto/threads.html > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.0.2_crypto_threads.html=DwMFAw=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=ZS_kRxGa4vj0O6wqfY-6q7kwVT0WiIMkFqw1XWHym4o=GK3QtuXP-8j_1nbRihxeJGLAIYXt1BNIyh3WHP6EJlY=>) > > > > * "OpenSSL can safely be used in multi-threaded applications > provided that at least two callback functions are set, > locking_function and threadid_func." > > > > * Is there any planning to fix this issue? > > > > > > Well, the most likely fix is to make the “safely” wording be more > vague, which I doubt you’ll like. But I doubt anyone on the team has > much interest in fixing 1.0.2 locking issues. > > Who said they were 1.0.2-specific? Master's obj_dat.c still has a completely unlocked OBJ_new_nid() that is a public API function; AFAICT the issue is still present. -Ben -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Blog post; changing in email, crypto policy, etc
➢ ah, true, I have those disabled because I use the same account for both my personal and my work projects so no single email address is correct for them At least we figured out the confusion! I have no good answer other than subject line filtering and forwarding, sorry. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Blog post; changing in email, crypto policy, etc
➢ github ones require me to go to the web UI which is slow I am confused by that. When someone posts an issue or comment, I get the text emailed to me. Not just openssl, but all projects I watch. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Blog post; changing in email, crypto policy, etc
➢ For the lovers of NNTP: openssl-project has been added to news.gmane.org as gmane.comp.encryption.openssl.project as readonly list. I will always have a fondness for NNTP :) But that reminds me to nudge the other mailing list distributors, and update the website. Thanks! -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Blog post; changing in email, crypto policy, etc
➢ this feature sends notifications about _all_ conversations happening. For me, I get the actual comments that are posted. Don’t you? On the mailing list, you have to explicitly mark/junk conversation threads in your mail program. You would still have to do that here. I don’t understand what you see as different? -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Blog post; changing in email, crypto policy, etc
You should be able to just watch the openssl repo (the eyeball/watch notice in the upper-right side) On 1/23/18, 7:00 AM, "Hubert Kario" <hka...@redhat.com> wrote: On Friday, 19 January 2018 18:34:57 CET Salz, Rich via openssl-dev wrote: > There’s a new blog post at > https://www.openssl.org/blog/blog/2018/01/18/f2f-london/ > We decided to increase our use of GitHub. In addition to asking that all bug > reports and enhancement requests be reported as issues, we now want all > major code proposals to be discussed as issues before a large pull request > shows up. This will let the community discuss the feature, offer input on > design and such, before having code to look at. We hope this will let us > all first look at the bigger picture, before getting bogged down in the > weeds of line-by-line code reviews. does that mean I have to subscribe to all notifications from the openssl github project to notice them? that's really suboptimal -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Blog post; changing in email, crypto policy, etc
➢ It appears to me that you could use openssl-dev instead of openssl-project, saving cycles on killing one and creating the other. We discussed that, but it would be harder to “undo” if things don’t work out, we wanted to make it very clear that this is a new way of operating, and openssl-project is a moderated list. Make sense? -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Blog post; changing in email, crypto policy, etc
There’s a new blog post at https://www.openssl.org/blog/blog/2018/01/18/f2f-london/ It contains some important policy changes we decided at our meeting last month. This includes: - Closing the openssl-dev mailing list; use GitHub for issues - New mailing list openssl-project for project discussions - New policy for accepting crypto algorithms, formats, and protocols. - .. several others Please read the posting; the changes described in it affect everyone who uses OpenSSL. Thanks for your interest, and all your efforts to help improve the project! -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] evp cipher/digest - add alternative to init-update-final interface
On 01/17/2018 12:04 PM, Patrick Steuer wrote: > libcrypto's interface for ciphers and digests implements a flexible > init-update(s)-final calling sequence that supports streaming of > arbitrary sized message chunks. > > Said flexibility comes at a price in the "non-streaming" case: The > operation must be "artificially" split between update/final. This > leads to more functions than necessary needing to be called to > process a single paket (user errors). It is also a small paket > performance problem for (possibly engine provided) hardware > implementations for which it enforces a superfluous call to a > coprocessor or adapter. > > libssl currently solves the problem, e.g for tls 1.2 aes-gcm record > layer encryption by passing additional context information via the > control interface and calling EVP_Cipher (undocumented, no engine > support. The analoguously named, undocumented EVP_Digest is just an > init-update-final wrapper). The same would be possible for tls 1.3 > pakets (it is currently implemented using init-update-final and > performs worse than tls 1.2 record encryption on some s390 hardware). > > I would suggest to add (engine supported) interfaces that can process a > paket with 2 calls (i.e. init-enc/dec/hash), at least for crypto > primitives that are often used in a non-streaming context, like aead > constructions in modern tls (This would also make it possible to move > tls specific code like nonce setup to libssl. Such interfaces already > exist in boringssl[1] and libressl[2]). > > What do you think ? The one-shot EVP_DigestSign() and EVP_DigestVerify() APIs were added to support the PureEdDSA algorithm, which is incapable of performing init/update/final signatures. That seems like precedent for adding such APIs for the other types of EVP functionality, though getting a non-wrapper implementation that actually allows ENGINE implementations would be some amount of work. -Ben -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] PKCS12 safecontents bag type deviation from spec
OpenSSL defines it as a SET OF and the spec says it’s a SEQUENCE OF. Ouch! Will that cause interop problems if we change it? (I don’t remember the DER encoding rules) -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-users] Failed to access LDAP server when a valid certificate is at .1+
On 01/09/2018 01:47 PM, Misaki Miyashita wrote: > >>> Sorry, I meant to say it is for the 1.0.2 branch. >>> >> Except in exceptional circumstances, code only ends up in the 1.0.2 >> branch after having first gotten into the master branch and then the >> 1.1.0 branch. The current release policy only allows bug fixes to be >> backported to the stable branches, not new features. To me, this code >> seems more like a new feature than a bugfix, though I do not claim to >> speak authoritatively on the matter. >> >> The preferred mechanism for submitting patches is as github pull >> requests (against the master branch, with a note in the pull request >> message if the backport is desired). > > Thank so much for your comment, Ben. > > We are planing to upgrade to the 1.1.0 branch as soon as we can which > is not so easy to do at this moment as we need the FIPS capability. > Thus, we are still focusing on the 1.0.2 release, and haven't had a > chance to work on the 1.1.0 branch. Thus, I won't be able to submit a > PR against the master branch at this moment. > > Thus, I was hoping to get a review on the suggested fix for the 1.0.2 > to see it is viable by the upstream first. > > Would it be possible to get a review on the openssl-dev@openssl.org > alias? or filing an issue via github is the right course of action? > You already got a review, from Viktor. I don't think there's much reason to file an issue in github without a patch (and if there's a patch, it should just go straight to a pull request with no separate issue). If you want the feature to get upstreamed, the onus is on you to forward-port the patch to master and adapt it to review comments; I don't think we've seen sufficient interest to cause a team member to spontaneously take that work upon themselves. -Ben > Thanks again for your comment. > > Regards, > > -- misaki -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Speck Cipher Integration with OpenSSL
I don’t think anyone is talking about OpenSSL depending on or requiring Apache; that’s a non-starter. It would be interesting to see how many changes you need to support your platform. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Speck Cipher Integration with OpenSSL
On 01/09/2018 08:32 AM, Randall S. Becker wrote: > On January 9, 2018 8:41 AM, Rich Salz >> ➢ We are currently modifying the source from Apache to OpenSSL open >> source >> licensing for the Speck/OpenSSL integration. Related repositories such >> as the cipher itself will remain under the Apache license. We would love >> input on the following items: >> >> Don’t bother changing the license. The future direction of OpenSSL is moving >> to Apache, anda it’s unlikely this work would show up in OpenSSL before we >> change the license. >> >> We’ll soon have a blog post about our current thoughts on a crypto policy. >> Watch this space. >> >> For discussion, the future-compatible thing to do :) is open a GitHub issue. >> Then, make a pull request after the issue discussion seems to have died >> down. > A request, maybe OT. The NonStop platform does broadly deploy Apache but do > use OpenSSL. I understand that OpenSSL does not officially support the HPE > NonStop NSE/NSX platforms - but it is used on the platform through my team's > port, which I currently support, and through other ports as well. Added a > dependency to Apache is likely to dead-end the project for us depending on > the depth of the dependency, if I understand where this is going (hoping I am > wrong). > Apache license, not Apache software. -Ben -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-users] Failed to access LDAP server when a valid certificate is at .1+
On 01/09/2018 12:53 AM, Misaki Miyashita wrote: > > > On 01/ 8/18 04:46 PM, Misaki Miyashita wrote: >> (switching the alias to openssl-dev@openssl.org) >> >> I would like to suggest the following fix so that a valid certificate >> at .x can be recognized during the cert validation even when >> .0 is linking to a bad/expired certificate. This may not be >> the most elegant solution, but it is a minimal change with low impact >> to the rest of the code. >> >> Could I possibly get a review on the change? and possibly be >> considered to be integrated to the upstream? >> (This is for the 1.0.1 branch) > > Sorry, I meant to say it is for the 1.0.2 branch. > Except in exceptional circumstances, code only ends up in the 1.0.2 branch after having first gotten into the master branch and then the 1.1.0 branch. The current release policy only allows bug fixes to be backported to the stable branches, not new features. To me, this code seems more like a new feature than a bugfix, though I do not claim to speak authoritatively on the matter. The preferred mechanism for submitting patches is as github pull requests (against the master branch, with a note in the pull request message if the backport is desired). -Ben -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Speck Cipher Integration with OpenSSL
➢ We are currently modifying the source from Apache to OpenSSL open source licensing for the Speck/OpenSSL integration. Related repositories such as the cipher itself will remain under the Apache license. We would love input on the following items: Don’t bother changing the license. The future direction of OpenSSL is moving to Apache, anda it’s unlikely this work would show up in OpenSSL before we change the license. We’ll soon have a blog post about our current thoughts on a crypto policy. Watch this space. For discussion, the future-compatible thing to do :) is open a GitHub issue. Then, make a pull request after the issue discussion seems to have died down. Hope this helps. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Speck Cipher Integration with OpenSSL
On 01/08/2018 03:10 PM, William Bathurst wrote: > Hi Hanno/all, > > I can understand your view that "more is not always good" in crypto. > The reasoning behind the offering can be found in the following > whitepaper: > > https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf > > > I will summarize in a different way though. We wish to offer an > optimized lightweight TLS for IoT. A majority of devices found in IoT > are resource constrained, for example a device CPU may only have 32K > of RAM. Therefore security is an afterthought by developers. For some > only AES 128 is available and they wish to use 256 bit encryption. > Then Speck 256 would be an option because it has better performance > and provides sufficient security. > > Based on the above scenario you can likely see why we are interested > in OpenSSL. First, OpenSSL can be used for terminating lightweight TLS > connections near the edge, and then forwarding using commonly used > ciphers. > > [IoT Device] -TLS/Speck---->[IoT Gateway]-TLS> [Services] > > Also, we are interested in using OpenSSL libraries at the edge for > client creation. One thing we would like to do is provide instructions > for an highly optimized build of OpenSSL that can be used for > contrained devices. > > I think demand will eventually grow because there is an initiative by > the US government to improve IoT Security and Speck is being developed > and proposed as a standard within the government. Therefore, I see > users who wish to play in this space would be interested in a version > where Speck could be used in OpenSSL. > > It is my hope to accomplish the following: > > [1] Make Speck available via Open Source, this could be as an option > or as a patch in OpenSSL. > [2] If we make it available as a patch, is there a place where we > would announce/make it known that it is available? > > We are also looking at open-sourcing the client side code. This would > be used to create light-weight clients that use Speck and currently we > also build basic OAuth capability on top of it. > Interestingly, the IETF ACE (Authentication and Authorization in Constrained Environments) is chartered to look at this space (crypto for constrained systems/IoT), and is aiming towards something roughly OAuth-shaped, but there has not really been any interest in Speck expressed that I've seen. So, is this work happening someplace else, or is there not actually demand for it? -Ben > Thanks for your input! > > Bill > > On 1/5/2018 11:40 AM, Hanno Böck wrote: >> On Fri, 5 Jan 2018 10:52:01 -0800 >> William Bathurst <wbath...@gmail.com> wrote: >> >>> 1) Community interest in such a lightweight cipher. >> I think there's a shifting view that "more is not always good" in >> crypto. OpenSSL has added features in the past "just because" and it >> was often a bad decision. >> >> Therefore I'd generally oppose adding ciphers without a clear usecase, >> as increased code complexity has a cost. >> So I think questions that should be answered: >> What's the usecase for speck in OpenSSL? Are there plans to use it in >> TLS? If yes why? By whom? What advantages does it have over existing >> ciphers? (Yeah, it's "lightweight", but that's a pretty vague thing.) >> >> >> Also just for completeness, as some may not be aware: There are some >> concerns about Speck due to its origin (aka the NSA). I don't think >> that is a reason to dismiss a cipher right away, what I'd find more >> concerning is that from what I observed there hasn't been a lot of >> research about speck. >> > -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Is X509_free(NULL) ok?
Yes you can do so. It is documented in most of the manpages, and in 1.1.0 and
later it should be in all of them.
On 1/1/18, 11:19 AM, "Ray Satiro via openssl-dev" <openssl-dev@openssl.org>
wrote:
I'm trying to figure out whether it's supported to call X509_free(NULL)
in 1.0.2 and beyond. It's not documented what action occurs when the
pointer is null. Also generally speaking is it supported to call openssl
free functions with null pointers?
--
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
Re: [openssl-dev] Is X509_free(NULL) ok?
➢So it's guaranteed for 1.1, mostly guaranteed for recent 1.0.2, but not guaranteed for older 1.0.2. yes. ➢ I also think it would be good to backport all to 1.0.2 Yes. I believe I did that, but I am not absolutely 100% positive. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Is X509_free(NULL) ok?
➢ I think we fixed all such cases in 1.1.0, all *_free() functions should handle NULL. I don't think we backported to changes to 1.0.2. Yes, and we fixed the documentation. I backported all/most of them to 1.0.2 to make cherry-picking easier. I don’t know if I changed the docs. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-users] Is X509_free(NULL) ok?
> if (ptr!= NULL) free(ptr); That shouldn’t be necessary for OpenSSL. If you find places where it is, please open an issue. ➢ BTW, "can handle" should explicitly say what happens. Perhaps use the C library text, which says: If ptr is NULL, no operation is performed. That is the wording we use. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Is X509_free(NULL) ok?
Our intent is that all FREE functions can handle NULL. If you find things missing or undocumented, please open an issue on GitHub. Thanks! -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Is X509_free(NULL) ok?
I'm trying to figure out whether it's supported to call X509_free(NULL) in 1.0.2 and beyond. It's not documented what action occurs when the pointer is null. Also generally speaking is it supported to call openssl free functions with null pointers? -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [07 Dec 2017] Read/write after SSL object in error state (CVE-2017-3737) == Severity: Moderate OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state" mechanism. The intent was that if a fatal error occurred during a handshake then OpenSSL would move into the error state and would immediately fail if you attempted to continue the handshake. This works as designed for the explicit handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()), however due to a bug it does not work correctly if SSL_read() or SSL_write() is called directly. In that scenario, if the handshake fails then a fatal error will be returned in the initial function call. If SSL_read()/SSL_write() is subsequently called by the application for the same SSL object then it will succeed and the data is passed without being decrypted/encrypted directly from the SSL/TLS record layer. In order to exploit this issue an application bug would have to be present that resulted in a call to SSL_read()/SSL_write() being issued after having already received a fatal error. This issue does not affect OpenSSL 1.1.0. OpenSSL 1.0.2 users should upgrade to 1.0.2n This issue was reported to OpenSSL on 10th November 2017 by David Benjamin (Google). The fix was proposed by David Benjamin and implemented by Matt Caswell of the OpenSSL development team. rsaz_1024_mul_avx2 overflow bug on x86_64 (CVE-2017-3738) = Severity: Low There is an overflow bug in the AVX2 Montgomery multiplication procedure used in exponentiation with 1024-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH1024 are considered just feasible, because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be significant. However, for an attack on TLS to be meaningful, the server would have to share the DH1024 private key among multiple clients, which is no longer an option since CVE-2016-0701. This only affects processors that support the AVX2 but not ADX extensions like Intel Haswell (4th generation). Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732 and CVE-2015-3193. Due to the low severity of this issue we are not issuing a new release of OpenSSL 1.1.0 at this time. The fix will be included in OpenSSL 1.1.0h when it becomes available. The fix is also available in commit e502cc86d in the OpenSSL git repository. OpenSSL 1.0.2 users should upgrade to 1.0.2n This issue was reported to OpenSSL on 22nd November 2017 by David Benjamin (Google). The issue was originally found via the OSS-Fuzz project. The fix was developed by Andy Polyakov of the OpenSSL development team. Note Support for version 1.0.1 ended on 31st December 2016. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20171207.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJaKUFJAAoJENnE0m0OYESRp1UH/1Z8hBb1dM82Lnn3b0pQ1LjF xBqs0cBFax6z8gelZzUI3CEJe78n3YB6jJiyCDOvrsrb9dx4kGvt97R9x9Np6glh /cL98I1mVwLdLciE1WeBPBFDijp5Bii4pz3q4StFGmh9g9cQ70onz8OO0RB9GSS5 dpbRcbOZLcyt3Lnqmnx86SLAdGgF635SO0EE10txDXjgEUK3Zo+gT+/jelwoNLXT mtYfqgXp6+Eqa08Qq3Nmrgqz4azhFLD5szixmnXQwbP+OpiT+zpNXsV5qqemWFn9 aV2qzDJJtrpObaPXSqKCBUA7C1qYmj9OmeaDUVJ29vS1mm09hs18if954ib6nbw= =MmWs -END PGP SIGNATURE- -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] OpenSSL version 1.0.2n published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 1.0.2n released === OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2n of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2n is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2n.tar.gz Size: 5375802 SHA1 checksum: 0ca2957869206de193603eca6d89f532f61680b1 SHA256 checksum: 370babb75f278c39e0c50e8c4e7493bc0f18db6867478341a832a982fd15a8fe The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2n.tar.gz openssl sha256 openssl-1.0.2n.tar.gz Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJaKT/tAAoJENnE0m0OYESR/JMH/jME2y7j63xd1JX1A41mgKiC y9ps1niQw6QVH50r2IR0bZc9EpM9WEF0zERjCPwvh/tCn2IS/40uGzdHps8aexV1 3p7F3oAyXfG3xPyY3p14zfRP+9YvatbVT28HVnhGmruUonS9p6H+4zQN4hd8LZQO tMZ5XtdmTbULdnlD6znBVECcUN2C+LQgaGZ5WCx8Wh8b7Wo3VT50+Jwv/VtmgLAf csQKJlD7qNQq9xZ+fMGAlWuAIeGPM4ck+bbvx2ZclVMJh98rPWMd9HniNWrtMkM4 y4z7cu7hLKlroFpgJKH9kWxlDDCSWE3pxb9RLidff1K3HFps5NDc41Rk8tYqcVU= =CjjY -END PGP SIGNATURE- -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] A question DH parameter generation and usage
You can re-use the keys, but then you get no forward secrecy, and sessions generated with one connection are vulnerable to another. Why are you using DH? Unless you have compelling reasons (interop with legacy), you really should use ECDHE. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] frequency and size of heartbeat requests
thanks Hanno and Rich. On Tue, 12/5/17, Hanno Böck <ha...@hboeck.de> wrote: Subject: Re: [openssl-dev] frequency and size of heartbeat requests To: openssl-dev@openssl.org Cc: "Jitendra Lulla" <lull...@yahoo.com> Date: Tuesday, December 5, 2017, 9:59 PM On Tue, 5 Dec 2017 19:14:41 + (UTC) Jitendra Lulla via openssl-dev <openssl-dev@openssl.org> wrote: > Could the solution be a restricted count of HB requests along with a > timer? No, the solution is to disable TLS heartbeats. I actually wanted to bring this up when I recently noticed that OpenSSL still enables the heartbeat extension by default in every clienthello it sends. In the whole Heartbleed aftermath nobody was ever able to tell me where TLS Heartbeats are used. It's a feature in order to have a feature. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] frequency and size of heartbeat requests
The purpose of the HEARTBEAT message is for DTLS applications to determine the maximum packet size and tune the application records accordingly. There is never any reason to use this in TCP-based TLS; that was an OpenSSL bug that enabled it there. The usefulness of HEARTBEAT even in DTLS is probably pretty small and it is probably safer to just turn it off. Spending time and code to “protect it” is probably not worth the effort. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] frequency and size of heartbeat requests
Hi, With an "intentionally corrupted" tls1_heartbeat() in Openssl 1.0.2l, heart beat requests with big payloads such as 16300 or slightly more can be repeatedly sent to the server. The server, religiously responds back with such big payloads after spending its cpu on encrypting/HMAC computing on the payload in the heartbeat response messages.. I confirmed the above with s_server/s_client. The RFC doesn't say anything about this possible exploit/DOS attack. The RFC also allows such big payloads. While such payloads might be meeting some requirement (PMTU computation ?),, the frequency of such big messages (continuous repeats) must certainly be controlled. I see that this extn is disabled in openssl-master but I could see that some servers (eg yahoo) do respond to heartbeat requests which means that they are running some ssl implementation (probably Openssl) which is vulnerable to continuous repeated big HB requests. Is the problem mentioned above a problem indeed or I am missing something ? Could the solution be a restricted count of HB requests along with a timer? Thanks Jitendra -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Known apps supporting tls max frag size extn
Thanks Joey. And I found the url for listing a server's tls extensions here: http://possible.lv/tools/hb/?domain=yahoo.com Do you know how we can enable/test the extensions using firefox or any other browser? On Mon, 12/4/17, Joey Yandle <xol...@gmail.com> wrote: Subject: Re: [openssl-dev] Known apps supporting tls max frag size extn To: "Jitendra Lulla" <lull...@yahoo.com>, openssl-dev@openssl.org Date: Monday, December 4, 2017, 5:13 AM > Also, I have lost the url of a website which used to analyze any given server ( eg www.yahoo.com) for its supporting various tls extensions. You provide the server url and it will display all the tls extns supported by that server. If you know of any such url, could you please help me with that also. > openssl s_client has an argument -tlsextdebug: $ openssl s_client -connect www.yahoo.com:443 -tlsextdebug CONNECTED(0003) TLS server extension "renegotiation info" (id=65281), len=1 0001 - TLS server extension "EC point formats" (id=11), len=4 - 03 00 01 02 TLS server extension "session ticket" (id=35), len=0 TLS server extension "heartbeat" (id=15), len=1 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Known apps supporting tls max frag size extn
Hi, Could anybody please help me in finding known standard apps ( eg browsers and servers) which support tls extension for maximum fragment size negotiation? Also, I have lost the url of a website which used to analyze any given server ( eg www.yahoo.com) for its supporting various tls extensions. You provide the server url and it will display all the tls extns supported by that server. If you know of any such url, could you please help me with that also. Thanks Jitendra -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] FIPS module for 1.1.x ?
FIPS remains a very important goal. Hopefully we’ll have more details to share in early December. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Problems building openssl on Solaris
I tested 1.1.0g on my solaris10 sparc machine and it worked fine, but I use opencsw packages with a more modern gcc (4.9.2). Essentially my build environment and build looks like this: # Install packages from opencsw pkgadd -d http://get.opencsw.org/now&& \ /opt/csw/bin/pkgutil -U && \ /opt/csw/bin/pkgutil -y -i bash && \ /opt/csw/bin/pkgutil -y -i nano && \ /opt/csw/bin/pkgutil -y -i bzip2&& \ /opt/csw/bin/pkgutil -y -i gtar && \ /opt/csw/bin/pkgutil -y -i ggrep&& \ /opt/csw/bin/pkgutil -y -i gsed && \ /opt/csw/bin/pkgutil -y -i gpatch && \ /opt/csw/bin/pkgutil -y -i wget && \ /opt/csw/bin/pkgutil -y -i perl && \ /opt/csw/bin/pkgutil -y -i top && \ /opt/csw/bin/pkgutil -y -i gmake&& \ /opt/csw/bin/pkgutil -y -i gcc4g++ && \ /opt/csw/bin/pkgutil -y -i gdb && \ /opt/csw/bin/pkgutil -y -i python && \ /opt/csw/bin/pkgutil -y -i cmake&& \ mkdir -p /usr/local/bin && \ ln -sf /opt/csw/bin/gtar /usr/local/bin/tar && \ ln -sf /opt/csw/bin/bash /usr/local/bin/bash && \ ln -sf /opt/csw/bin/ggrep /usr/local/bin/grep && \ ln -sf /opt/csw/bin/gsed /usr/local/bin/sed && \ ln -sf /opt/csw/bin/gmake /usr/local/bin/make && \ ln -sf /opt/csw/bin/gpatch /usr/local/bin/patch # Start a Bash shell /opt/csw/bin/bash # Set up environment export PATH=/opt/csw/bin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/X/bin:/usr/ccs/bin export LD_LIBRARY_PATH=/opt/csw/lib:/opt/csw/lib/64:/usr/sfw/lib export LD_LIBRARY_PATH_64=$LD_LIBRARY_PATH # build and install openssl 1.1.0g wget https://www.openssl.org/source/openssl-1.1.0g.tar.gz && \ tar -zxvpf openssl-1.1.0g.tar.gz && \ cd openssl-1.1.0g && \ KERNEL_BITS=64 ./config --prefix=/usr/local/ssl-1.1.0g && \ make && \ make install # Verify LD_LIBRARY_PATH_64=/usr/local/ssl-1.1.0g/lib:$LD_LIBRARY_PATH_64 /usr/local/ssl-1.1.0g/bin/openssl version OpenSSL 1.1.0g 2 Nov 2017 On 11/17/17 5:46 AM, Dmitry Belyavsky wrote: Dear Richard, Adding no-threads just removes gcc complaint about -pthreads. On Fri, Nov 17, 2017 at 1:23 PM, Richard Levitte <levi...@openssl.org <mailto:levi...@openssl.org>> wrote: I suggest adding 'no-threads' to the OpenSSL configuration options, at least as a first step. That should at least take away gcc's complaint about '-pthread'... I cannot say if that'll fix the rest, I don't know Solaris enough. Cheers, Richard In message <cadqlbzkeqxgafwggaz5gyrqp9xgewjfj2fvtkln9srnrej+...@mail.gmail.com <mailto:cadqlbzkeqxgafwggaz5gyrqp9xgewjfj2fvtkln9srnrej%2b...@mail.gmail.com>> on Fri, 17 Nov 2017 11:08:34 +0300, Dmitry Belyavsky <beld...@gmail.com <mailto:beld...@gmail.com>> said: beldmit> Hello, beldmit> beldmit> We experience problems building OpenSSL on Solaris. beldmit> beldmit> /usr/local/src/openssl-1.1.0g>uname -a beldmit> beldmit> SunOS pooh.tcinet.ru <http://pooh.tcinet.ru> 5.10 Generic_147147-26 sun4u sparc SUNW,SPARC-Enterprise beldmit> beldmit> /usr/local/src/openssl-1.1.0g>gcc -v beldmit> beldmit> Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs beldmit> Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared beldmit> --enable-languages=c,c++,f77 beldmit> Thread model: posix beldmit> gcc version 3.4.6 beldmit> beldmit> OpenSSL 1.1.0g is configured via beldmit> ./Configure solaris64-sparcv9-gcc beldmit> beldmit> Here is the end of output: beldmit> beldmit> ... beldmit> beldmit> LD_LIBRARY_PATH=.:/usr/local/ssl/lib:/usr/sfw/lib/sparcv9:/usr/local/lib gcc -DDSO_DLFCN beldmit> -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE beldmit> -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM beldmit> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM beldmit> -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/engines-1.1" -m64 beldmit> -mcpu=ultrasparc -Wall -DB_ENDIAN -DBN_DIV2W -O3 -pthread -DFILIO_H -o apps/openssl beldmit> apps/app_rand.o apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o beldmit> apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o beldmit> apps/enc.o apps/engine.o
[openssl-dev] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [02 Nov 2017] bn_sqrx8x_internal carry bug on x86_64 (CVE-2017-3736) == Severity: Moderate There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. This only affects processors that support the BMI1, BMI2 and ADX extensions like Intel Broadwell (5th generation) and later or AMD Ryzen. Note: This issue is very similar to CVE-2017-3732 and CVE-2015-3193 but must be treated as a separate problem. OpenSSL 1.1.0 users should upgrade to 1.1.0g OpenSSL 1.0.2 users should upgrade to 1.0.2m This issue was reported to OpenSSL on 10th August 2017 by the OSS-Fuzz project. The fix was developed by Andy Polyakov of the OpenSSL development team. Malformed X.509 IPAddressFamily could cause OOB read (CVE-2017-3735) Severity: Low This issue was previously announced in security advisory https://www.openssl.org/news/secadv/20170828.txt, but the fix has not previously been included in a release due to its low severity. OpenSSL 1.1.0 users should upgrade to 1.1.0g OpenSSL 1.0.2 users should upgrade to 1.0.2m Note Support for version 1.0.1 ended on 31st December 2016. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20171102.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJZ+y3yAAoJENnE0m0OYESRWooH/2cS+HkzBCCdnJ/CWuhKomTe hshdBbYw/eYeZgrUYZX6CYosvhLX1Hkwef3vVMxHDXsnBnnZfGfwCS2EfXJ96xXK KiXVchBwlpmovrOuAvrGtPqLkiVOZZpGMfopP30WCKc6tkdqjw/NvruMbg7Iz+Sy ki5AM7Vw7kAEa18KAGjSN4jSrCHMIKkOeGkmay5hHlYLwQRQDAAo5EmWmVOJpUXF ddvQ6h+NKqlWAMF+2/U3PhUFa4V7xqlKR3GMdRawVSaoKQUsPXvRGAhLnvqfOonx y0yl7y9a7EJrcRl8HWf7qqZf0B/m3YapCHNNcBYWry+qk7LJgGjIHDF8VFkEABg= =k+bJ -END PGP SIGNATURE- -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] OpenSSL version 1.1.0g published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 1.1.0g released === OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.0g of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.0-notes.html OpenSSL 1.1.0g is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0g.tar.gz Size: 5404748 SHA1 checksum: e8240a8be304d4317a750753321b073c664bfdd4 SHA256 checksum: de4d501267da39310905cb6dc8c6121f7a2cad45a7707f76df828fe1b85073af The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0g.tar.gz openssl sha256 openssl-1.1.0g.tar.gz Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJZ+yu1AAoJENnE0m0OYESRqkkH/3LhY0dicqyjbrE/COsUmHsi TWjd35afOl5N1LRouz7lhLE1lQsKXP67h5FCXsuCvmqwk4sJu6ItfeHOBQqkL41Q 9GS1jXasJwB4EQ0cYIPQwjC+DN1H+TWj9AYeCrvnfBTczTOujW7neEUVH2yuknk0 Gd+KOdhCIvVRxEucDQPmoza+yESpZNY01VPtGutjMAp2WDq+rYm9MUqUyAYzbRhj 5EgHx1ZRrmOU3//qsMC6sNea3uUyQL+AHdKHAsAP1QgeVEJoEgxi283FNG9cYvRh ZaaV9qZzg26dubXfOjUkIW7DxMyQ64WwIwJWDL/GtQwBLKIr5hvWqEYRnllvbZE= =I8uX -END PGP SIGNATURE- -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] OpenSSL version 1.0.2m published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 1.0.2m released === OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2m of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2m is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2m.tar.gz Size: 5373776 SHA1 checksum: 27fb00641260f97eaa587eb2b80fab3647f6013b SHA256 checksum: 8c6ff15ec6b319b50788f42c7abc2890c08ba5a1cdcd3810eb9092deada37b0f The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2m.tar.gz openssl sha256 openssl-1.0.2m.tar.gz Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJZ+yzNAAoJENnE0m0OYESRd2UIAK0+Ht1wVP/VaL97rv7l4aBp l5JRH/0OnvIwvGh5CEGywY5MDXWZisMAzDB8AeNtDfGcN3eMDJkUITglT6EiDavF P4g3ZoK+JPJRER4i3S8z33z6x8yUBMZ26o0xVvI/JndsPGxa5oTLOGVYAi9YNwGu /IYuuYfZctzY/kVzlVn1AsoorD7trwsvAzh2bBCyWELJx3s7D40riQ8NpElmHXTg InSQRZmb83i70RYEqYTwSKKpCUjaUSZeUo3OWgzxoQfTh4IshlyB1Pdrwab7x69l gsLx914YkO+i388lqGTIMpCsdFVnu9Feap8Q2L+HsyIsnN8M8ZSvqudV6di9EO4= =al6h -END PGP SIGNATURE- -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] New crypto algorithms in openSSL engine
>@Victor; Are you saying so that the patches that enabled the GOST ciphersuite be added are not included in openSSL? If so, would that mean it's not possible for me to fork off openSSL and follow the GOST template? Not quite. He’s saying that adding new crypto to TLS requires some static tables in libssl to be updated. Some new “NID” variables in objects.txt, and so on. The implementation of the algorithm can be done as an ENGINE. >Putting engines aside for a moment, given that I have the appropriate headers for the crypto library I want to use, and I can build a shared or static library for it... would it be a viable option to try and integrate those headers and libraries directly into openSSL? Maybe. Hence the term “research” :) -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] New crypto algorithms in openSSL engine
➢ Really, about a ten years ago, when we first developed GOST engine, we have made patches, that allow to add ciphersuites dynamically. Unfortunately, that time core team haven't accepted these patches. Do you still have them available? We might make a different choice now … -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)
On 10/04/2017 04:30 AM, Matt Caswell wrote: > > Looks like we should have an exception for this case (with a suitable > comment explaining why). Will you create a PR? > Yes, I was planning to. I was just taking some time to ponder whether it's worth burning an option bit on, to allow an opt-out (probably not). -Ben -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Can I haz TLS 1.3 ?
Can the people involved in these Tests please speak up what's going on here? Particularly can you please name vendor names? Tbe TLSWG mailing list is probably a more effective place to have that discussion; I was just informing the OpenSSL community of the state of play ;) -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Can I haz TLS 1.3 ?
Some people have asked why TLS 1.3 isn’t available yet. This might help; it’s
a draft of a posting for my company’s blog.
Can I Haz TLS 1.3 ?
Everybody wants to be able to use TLS 1.3. Among the reasons are:
It’s faster – being able to reconnect to a server you’ve
previously used, and saving a full round-trip latency is impressive.
It’s more reliable – the protocol has been cleaned up and
simplified. For example, the related concepts of sessions, tickets, and
pre-shared keys are merged and treated consistently. To a protocol designer, it
is much more elegant, and therefore much easier to implement
It’s more secure – Many world-class cryptographers have been
involved in the protocol design, analyzed it, and tried to break it.
TLS has been in the “last call” for several weeks now. What does that mean,
and what’s holding it up?
The IETF is the organization that defines most of the standards that define how
the Internet works. They cover everything from naming (DNS) to routing around
firewalls, up to and including HTTP. The documents, known as RFCs, are created
by working groups, passed to a steering committee for review, and then
published as “Internet Standards.”
Participation in a working group (WG) is, by design, very easy and not a lot of
overhead. You just have to join a mailing list. Every WG has a mailing list
and there are currently more than 110 working groups hosted at the IETF. Each
one has a status page, that shows their charter (what they are working on), the
current sent of documents, and pointers to the mailing lists. For the TLS
working group, that page is at https://datatracker.ietf.org/wg/tls/documents/.
Future RFC’s start as Internet-Drafts. Each draft usually goes through multiple
revisions, as the working group members comment on it, other feedback is
addressed, and so on. At some point, the authors or editors will post a new
draft. By convention, every working group draft is named
“draft-ietf-{WGNAME}-{subject}-{nn}” where {WGNAME} is the name of the working
group, {subject} is the name of the document, and {nn} is the revision number.
For example, “draft-ietf-tls-tls13-21” is the 21st draft of the TLS 1.3
specification from the TLS working group.
When the working group thinks a document is done, it enters WGLC, working group
last call. This period, usually lasting a couple of weeks, is the last chance
to make editorial or serious factual fixes. Since most people are
deadline-driven, this is usually when many on the WG wake up and read the
drafts. After WGLC, it goes to the IESG (technical leadership basically) for
review. As I said, TLS 1.3 has been in WGLC for weeks. So why can’t we use it
yet?
First, the different drafts don’t interoperate. Each represents a different
milestone on the way to the full specification, and a flag in the header
identifies which draft is being used. OpenSSL, used by most of the servers on
the Internet, is currently at draft-21. Chrome and Firefox, two of the most
popular browsers on the Internet, are staying at draft-18; they don’t want to
upgrade until we have the final version. (I think that’s silly, but I don’t
work for either browser.)
Tests run by various companies, including Google, Mozilla, and Facebook,
indicate that the “failure rate” of TLS 1.3 is disturbingly high. It appears
that network hardware such as routers, gateways, load balancers and the like,
are blocking TLS 1.3 packets because they don’t recognize the protocol. They
are doing “fail closed” and block the connections because they don’t understand
it, rather than assuming it’s safe to forward. The IETF often uses the term
“middlebox” to describe such hardware that operates between endpoints, and this
type of behavior that blocks new protocols as “ossificiation.” The various
companies, and no doubt others, are trying experiments to tweak the protocol to
lower the failure rate. For example, in some circumstances it might be
acceptable to make a TLS 1.3 message look like a TLS 1.2 message (after you’ve
already committed to doing TLS 1.3).
So far nobody has released any details. When it happens, it will be on the
TLS-WG mailing list, which you can find at the page I referenced above. Until
then, because of the draft differences, it’s impractical to run even limited
deployment tests unless you’re willing to work with bleeding edge releases and
undocumented flags. That’s unfortunate, and we all hope that the situation will
be improved by the next IETF meeting in November. Until then, we just have to
sit tight and wait.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)
It's just that extension in our experience. Enforcing that servers don't send extensions they aren't supposed to generally works fine and is good for the ecosystem. But that particular extension needs a quirk. I suspect there was some confusion because ec_point_format_list can be server-sent in TLS 1.2 while elliptic_curves cannot. To be honest, I think that was just a mistake in RFC 4492. TLS 1.2 has no way for the server to tell the client what curves are acceptable for client certificates while the converse is possible. (TLS 1.3 avoids this mess entirely with SignatureScheme.) I do not know how widespread this one is. It looks like we coincidentally retained the quirk for this extension in BoringSSL when we first rewrote our extension-handling from the 1.0.2 code. Later on, I encountered the issue unrelatedly (I was probing some servers with some custom Go code), noticed we were already tolerant of this, and merely added a clarifying comment: https://boringssl.googlesource.com/boringssl/+/4ac2dc4c0d48ca45da4f66c40e60d6b425fa94a3 (Speaking of which, I think I forgot to inform the vendor. I'll send them a note.) David On Tue, Oct 3, 2017 at 11:16 AM Benjamin Kaduk via openssl-dev < openssl-dev@openssl.org> wrote: > Hi all, > > Doing some testing with a snapshot of master (s_client with -tls1_2 and > optionally a cipherspec that prefers ECDHE ciphers), we're running into > a sizeable number of servers that are sending extension 0xa (formerly > "elliptic_curves", now "supported_groups") in the ServerHello. This is > not supported by RFC 7919 or RFC 4492 (the server is supposed to > indicate it's selected curve/group in the ServerKeyExchange message > instead), or by the TLS 1.3 draft spec (which permits "supported_groups" > in EncryptedExtensions, so the client can update a cache of groups > supported by the server). > > In OpenSSL 1.1.0 we seem to have treated the elliptic_curves extension > in a ServerHello as an extension unknown to the library code and passed > it off to the custom extension handler. With the extension processing > rework in master done to support TLS 1.3, which admits extensions in > many more contexts than previously, we now check that a received > extension is allowable in the context at hand. In the table of > extensions, supported_groups is marked only as allowable in the > ClientHello and TLS 1.3 EncryptedExtensions, per the spec. However, > this new strict behavior causes connection failures when talking to > these buggy servers. So far we've seen this behavior from servers that > send a Server: header indicating Microsoft-IIS/7.5 and just "Apache". > > This raises some question of what behavioral compatibility is desired > between 1.1.0 and 1.1.1 -- do we need to disable the "extension context" > verification for ServerHello processing entirely, or maybe just for the > one extension known to cause trouble in practice? Or should we have an > SSL/SSL_CTX option to control the behavior (and which behavior should be > the default)? > > Also, I'd be interested in hearing whether anyone else has observed this > sort of behavior. > > Thanks, > > Ben > -- > 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] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)
Hi all, Doing some testing with a snapshot of master (s_client with -tls1_2 and optionally a cipherspec that prefers ECDHE ciphers), we're running into a sizeable number of servers that are sending extension 0xa (formerly "elliptic_curves", now "supported_groups") in the ServerHello. This is not supported by RFC 7919 or RFC 4492 (the server is supposed to indicate it's selected curve/group in the ServerKeyExchange message instead), or by the TLS 1.3 draft spec (which permits "supported_groups" in EncryptedExtensions, so the client can update a cache of groups supported by the server). In OpenSSL 1.1.0 we seem to have treated the elliptic_curves extension in a ServerHello as an extension unknown to the library code and passed it off to the custom extension handler. With the extension processing rework in master done to support TLS 1.3, which admits extensions in many more contexts than previously, we now check that a received extension is allowable in the context at hand. In the table of extensions, supported_groups is marked only as allowable in the ClientHello and TLS 1.3 EncryptedExtensions, per the spec. However, this new strict behavior causes connection failures when talking to these buggy servers. So far we've seen this behavior from servers that send a Server: header indicating Microsoft-IIS/7.5 and just "Apache". This raises some question of what behavioral compatibility is desired between 1.1.0 and 1.1.1 -- do we need to disable the "extension context" verification for ServerHello processing entirely, or maybe just for the one extension known to cause trouble in practice? Or should we have an SSL/SSL_CTX option to control the behavior (and which behavior should be the default)? Also, I'd be interested in hearing whether anyone else has observed this sort of behavior. Thanks, Ben -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Patch for iOS compilation failure on Xcode 9 / iOS 11 SDK
"-fomit-frame-pointer" is no longer allowed for armv7 targets, so I removed
it from the iphoneos-cross configure target. I noticed this
on openssl-1.0.2l.
--- Configure.orig 2017-05-25 05:54:38.0 -0700
+++ Configure 2017-09-29 12:09:45.0 -0700
@@ -652,7 +652,7 @@
"debug-darwin64-x86_64-cc","cc:-arch x86_64 -ggdb -g2 -O0 -DL_ENDIAN
-Wall::-D_REENTRANT:MACOSX:-Wl,-search_paths_first%:SIXTY_FOUR_BIT_LONG
RC4_CHUNK DES_INT DES_UNROLL:".eval{my
$asm=$x86_64_asm;$asm=~s/rc4\-[^:]+//;$asm}.":macosx:dlfcn:darwin-shared:-fPIC
-fno-common:-arch x86_64 -dynamiclib:.\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib",
"debug-darwin-ppc-cc","cc:-DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DCRYPTO_MDEBUG
-DB_ENDIAN -g -Wall -O::-D_REENTRANT:MACOSX::BN_LLONG RC4_CHAR RC4_CHUNK
DES_UNROLL
BF_PTR:${ppc32_asm}:osx32:dlfcn:darwin-shared:-fPIC:-dynamiclib:.\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib",
# iPhoneOS/iOS
-"iphoneos-cross","llvm-gcc:-O3 -isysroot \$(CROSS_TOP)/SDKs/\$(CROSS_SDK)
-fomit-frame-pointer
-fno-common::-D_REENTRANT:iOS:-Wl,-search_paths_first%:BN_LLONG RC4_CHAR
RC4_CHUNK DES_UNROLL BF_PTR:${no_asm}:dlfcn:darwin-shared:-fPIC
-fno-common:-dynamiclib:.\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib",
+"iphoneos-cross","llvm-gcc:-O3 -isysroot \$(CROSS_TOP)/SDKs/\$(CROSS_SDK)
-fno-common::-D_REENTRANT:iOS:-Wl,-search_paths_first%:BN_LLONG RC4_CHAR
RC4_CHUNK DES_UNROLL BF_PTR:${no_asm}:dlfcn:darwin-shared:-fPIC
-fno-common:-dynamiclib:.\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib",
# A/UX
"aux3-gcc","gcc:-O2 -DTERMIO::(unknown):AUX:-lbsd:RC4_CHAR RC4_CHUNK
DES_UNROLL BF_PTR:::",
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Bug: digest parameter is rejected
On 09/18/2017 09:32 AM, Blumenthal, Uri - 0553 - MITLL wrote: > > RSA-OAEP supports different hash functions and MGF. SHA-1 is the default. > > > > OpenSSL implementation of OAEP wrongly refuses to set the hash > algorithm, preventing one from using SHA-2 family: > > You'll probably need to pick up master and its -rsa_mgf1_md argument to pkeyutl. -Ben -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] TLS 1.3 client hello issue
On 09/18/2017 01:07 AM, Mahesh Bhoothapuri wrote:
>
> Hi,
>
> I am sending a Tls 1.3 client hello, and am seeing an issue with
>
> ossl_statem_client_write_transition in statem_clnt.c.
>
>
> /*
> * Note that immediately before/after a ClientHello we don't know what
> * version we are going to negotiate yet, so we don't take this
> branch until
> * later
> */
>
> /*
> * ossl_statem_client_write_transition() works out what handshake state to
> * move to next when the client is writing messages to be sent to the
> server.
> */
> WRITE_TRAN ossl_statem_client_write_transition(SSL *s)
> {
>
> if (SSL_IS_TLS13(s))
> return ossl_statem_client13_write_transition(s);
> }
>
> And in:
>
>
> /*
> * ossl_statem_client_write_transition() works out what handshake state to
> * move to next when the client is writing messages to be sent to the
> server.
> */
> WRITE_TRAN ossl_statem_client_write_transition(SSL *s)
> {
>
> /*
> * Note: There are no cases for TLS_ST_BEFORE because we haven't
> negotiated
> * TLSv1.3 yet at that point. They are handled by
> * ossl_statem_client_write_transition().
> */
>
> switch (st->hand_state) {
> default:
> /* Shouldn't happen */
> return WRITE_TRAN_ERROR;
>
> }
>
> With a TLS 1.3 client hello, using tls 1.3 version, the st->hand_state is
Sorry, I just want to clarify what you are doing -- are you taking
SSL_CTX_new(TLS_method()) and then calling
SSL_CTX_set_min_proto_version(ctx, TLS1_3_VERSION) and
SSL_CTX_set_max_proto_version(ctx, TLS1_3_VERSION)?
I note that there is no version-specific TLSv1_3_method() available, and
in any case, it's of questionable wisdom to attempt to force TLS 1.3
only while the specification is still in draft status -- in any case
where the client and server implementations are not tightly controlled,
negotiation failures seem quite likely.
> TLS_ST_BEFORE and so, the default error is returned.
>
> When I added :
>
> case TLS_ST_BEFORE:
> st->hand_state = TLS_ST_CW_CLNT_HELLO;
> return WRITE_TRAN_CONTINUE;
>
The reason there is not currently a case for TLS_ST_BEFORE is that
whether or not we're going to be using TLS 1.3 is supposed to be
determined on the server as part of version negotiation, so when we're
sending a ClientHello, our version is in an indeterminate status -- the
general-purpose TLS method must be used at that part of the handshake.
> The client hello gets sent out, but I only saw a TLS 1.2 version being
> sent.
> Is this a bug?
The legacy_version field in a TLS 1.3 ClientHello will be 0x0303,
matching the historical value for TLS 1.2. The actual list of versions
are conveyed in a "supported_versions" extension, which is what you need
to be looking at.
-Ben
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] libcrypto.pc needs to list libpthread as a dependency
Roumen Petrov wrote:
Howard Chu via openssl-dev wrote:
In OpenSSL 1.1 on Linux (at least) libcrypto now has a dependency on
libpthread but this is not reflected in the pkgconfig file. As a result,
tools like CMake fail to detect libcrypto properly when linking against the
static library. libpthread should be added to the Libs.private line of the
pkgconfig file.
For example:
https://github.com/monero-project/monero/issues/2402#issuecomment-327514216
Problem is that OpenSSL does not add it directly.
Build process does not know libraries added by compiler flags like -pthread.
Does not look like OpenSSL issue.
That sounds like a lame cop-out. Currently the build process already knows
that -ldl goes in ${EX_LIBS}. The Makefile is full of system-dependent
settings already.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] libcrypto.pc needs to list libpthread as a dependency
In OpenSSL 1.1 on Linux (at least) libcrypto now has a dependency on libpthread but this is not reflected in the pkgconfig file. As a result, tools like CMake fail to detect libcrypto properly when linking against the static library. libpthread should be added to the Libs.private line of the pkgconfig file. For example: https://github.com/monero-project/monero/issues/2402#issuecomment-327514216 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OPenssl 1.1.0 and FIPS
> FIPS is not supported for 1.1.0 > >jUST A SMALL FIX WILL DO. No. All of the FIPS supporting code has been pulled out of 1.1.0 Even if you get it to compile, it will fail at link or runtime because of missing functions. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OPenssl 1.1.0 and FIPS
Tryong to compile Fips into OPEnssl-1.1.0 and I run into FIPS is not supported for 1.1.0 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] 20170914 snapshots
We did some system upgrades and they were down during the update time. As I’ve said before, please wait for at least a second day before writing about the snapshots. On 9/14/17, 8:09 AM, "The Doctor" <doc...@doctor.nl2k.ab.ca> wrote: They are missing in action! -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] id-kp-OCSPSigning extended key usage
Bonjour, SHALL is not equivalent to a SHOULD, but to a MUST. See RFC2119. Cordialement, Erwann Abalea Le 12 sept. 2017 à 02:46, Winter Mute <zshr...@gmail.com<mailto:zshr...@gmail.com>> a écrit : Hello, The RFC<https://tools.ietf.org/html/rfc6960#section-4.2.2.2> states that: OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extended key usage certificate extension included in the OCSP response signer's certificate. The use of "SHALL" rather than "MUST" indicates that this recommendation can be ignored. How does openssl handle OCSP responses signed by certificates that do not have id-kp-OCSPSigning in the extended key usage certificate extension when the responses are not signed by the issuing CA directly? What informs this decision/policy? Are there any security implications in including or excluding OCSP-sign in the extended key usage extension? -- 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
Re: [openssl-dev] id-kp-OCSPSigning extended key usage
➢ Thanks for the clarification. Per the spec, then, a certificate designated to sign OCSP responses is required to have the ocsp-sign bit in the key usage extensions set. ➢ How does openssl handle cases where this requirement is violated? Look at check_delegated() in ocsp/ocsp_vfy.c It returns an error. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] X509_cmp_time (possible) bug
Correct,
But if one want’s strcmp()’s behavior (i.e. 0 is equality),
ASN1_TIME_cmp_time_t() will work (and was written because X509_cmp_time()
couldn’t be changed without breaking other things).
--
-Todd Short
// tsh...@akamai.com<mailto:tsh...@akamai.com>
// "One if by land, two if by sea, three if by the Internet."
On Sep 11, 2017, at 10:43 AM, Daniel Kahn Gillmor
<d...@fifthhorseman.net<mailto:d...@fifthhorseman.net>> wrote:
On Mon 2017-09-11 14:16:11 +0000, Short, Todd via openssl-dev wrote:
Yes, it’s annoying, but it’s historic. I looked into changing this at one point.
I think Dimitry's point was that the documentation doesn't match the
implementation because of the flexibility of strcmp's defined return
code.
However, i think commit 80770da39ebba0101079477611b7ce2f426653c5 ("X509
time: tighten validation per RFC 5280") resolves Dmitry's concerns.
--dkg
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] X509_cmp_time (possible) bug
Yes, it’s annoying, but it’s historic. I looked into changing this at one point.
I recommend using ASN1_TIME_cmp_time_t() (from the master branch) instead, for
the results you are expecting.
--
-Todd Short
// tsh...@akamai.com<mailto:tsh...@akamai.com>
// "One if by land, two if by sea, three if by the Internet."
On Sep 9, 2017, at 10:10 AM, Dmitry Belyavsky
<beld...@gmail.com<mailto:beld...@gmail.com>> wrote:
Hello,
The X509_cmp_time function is documented as returning -1 or 1 on success and 0
on error.
In fact it returns result of strcmp:
int X509_cmp_time(const ASN1_TIME *ctm, time_t *cmp_time) {
...
i = strcmp(buff1, buff2);
if (i == 0) /* wait a second then return younger */
return -1;
else
return i;
}
According to documentation to the strcmp,
The strcmp() and strncmp() functions return an integer less than, equal to, or
greater than zero if s1 (or the first n bytes thereof) is found,
respectively, to be less than, to match, or be greater than s2.
It means (and have been met in practice) that X509_cmp_time() returns other
values than 1/-1.
So it seems reasonable to either update documentation or fix the behavior.
Thank you!
--
SY, Dmitry Belyavsky
--
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
Re: [openssl-dev] QUIC
On 09/06/2017 05:24 PM, Matt Caswell wrote: > Issue 4283 (https://github.com/openssl/openssl/issues/4283) has caused > me to take a close look at QUIC. This seems to have been getting a *lot* > of attention just recently. See the IDs below for details: Yes, it's generated a lot of excitement and interest at the IETF. > https://tools.ietf.org/html/draft-ietf-quic-transport-05 > https://tools.ietf.org/html/draft-ietf-quic-tls-05 > https://tools.ietf.org/html/draft-ietf-quic-recovery-05 > > For the uninitiated QUIC is a new general-purpose transport protocol > built on top of UDP. It provides applications with a secure stream > abstraction (like TLS over TCP) with reliable, in-order delivery, as > well as the ability to multiplex many streams over a single connection > (without head-of-line blocking). > > It is *very* closely integrated with TLSv1.3. It uses the TLSv1.3 > handshake for agreeing various QUIC parameters (via extensions) as well > as for agreeing keying material and providing an "early data" > capability. The actual packet protection is done by QUIC itself (so it > doesn't use TLS application data) using a QUIC ciphersuite that matches > the negotiated TLS ciphersuite. Effectively you can think of QUIC as a > modernised rival to TLS over TCP. The nature of the QUIC/TLSv1.3 integration is somewhat interesting. QUIC has its origins at Google, and the "Google QUIC" or gQUIC variant is deployed on the public internet even now; since TLS 1.3 was not available then, it uses a separate "quic-crypto" scheme for these purposes. quic-crypto, in turn, helped shape the evolution of TLS 1.3, including the strong desire for 0-RTT functionality. But, as I understand it, the intent is to leave enough hooks that a different crypto layer could be used, including (but not limited to) a subsequent version of TLS. > I've spent some time today reading through the IDs. It has become clear > to me that in order for OpenSSL to be used to implement QUIC there are a > number of new requirements/issues we would need to address: > > - We need to provide the server half of the TLSv1.3 cookie mechanism. At > the moment an OpenSSL client will echo a TLSv1.3 cookie it receives back > to the server, but you cannot generate a cookie on the server side. Yeah, the cookie is pretty clear to the UDP/"stateless" operation. > - We need to be able to support *stateless* operation for the > ClientHello->HelloRetryRequest exchange. This is very much in the same > vein as the stateless way that DTLSv1_listen() works now for DTLS in the > ClientHello->HelloVerifyRequest exchange. This is quite a significant > requirement. The expectation is that the state gets bundled into the cookie, yes. > - A QUIC server needs to be able to issue a NewSessionTicket on demand > > - Ticket PSKs need to be able to have an embedded QUIC layer token (the > equivalent of the cookie - but embedded inside the PSK). I think https://github.com/openssl/openssl/pull/3802 is pretty close, in this space. > - We need to extend the "exporter" API to allow early_secret based > exports. At the moment you can only export based on the final 1-RTT key. It seems in keeping with our existing handling of early data, to at least consider providing a separate API for these early exporter values. > - TLS PSKs are transferable between TLS-TCP and QUIC/TLS-UDP. There are > some special rules around ALPN for this that may impact our current > logic in this area. > > - Possibly a QUIC implementation will need to have knowledge of the > TLSv1.3 state machine because different TLSv1.3 handshake records need > to go into different types of QUIC packets (ClientHello needs to go into > "Client Initial" packet, HelloRetryRequest needs to go into a "Server > Stateless Retry" packet and everything else goes into "Client Cleartext" > or "Server Cleartext" packets). It may be possible for a QUIC > implementation to infer the required information without additional > APIs, but I'm not sure. We do have existing things like the message callback, but I won't try to argue that that's an ideal situation for a QUIC implementor. And the QUIC layer could even parse out the unencrypted records for itself from the output BIO, as silly as that would be. > - QUIC places size limits on the allowed size of a ClientHello. Possibly > we may want some way of failing gracefully if we attempt to exceed that > (or maybe we just leave that to the QUIC implementation to detect). (This is to limit the potential for a DoS amplification attack via spoofed client address, since UDP does not provide the reachability confirmation that TCP's handshake does, for the spectators.) > I'm going to start working through this list of requirements,
Re: [openssl-dev] 1.1.1 master consistently fails (was Re: openssl 1-1-0-stable fails)
Ø Config & build script (feel free to suggest improvements, BTW): Perhaps don’t cut/paste green-on-black color? Plaintext is probably sufficient. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] How to use BIO_do_connect(), blocking and non-blocking with timeout, coping with errors
FWIW, there’s a ‘libtls’ library from the libre folks that might be worth looking at. If you come up with useful snippets we can start by posting them to the wiki, for example -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-users] how to compile out selected ciphers
What version of openssl are you building? -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Plea for a new public OpenSSL RNG API
➢ > Sure I can. Because the DRBG seeds from the system anyway ➢ You can't assume that will work for all users. And for places where the systesm doen’t have enough randomness, there is nothing we can do. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Plea for a new public OpenSSL RNG API
➢ But now we just ignore it and assume every bit with get contains 1 ➢ bit of randomness and we're sundenly seriously overestimating the ➢ amount of randomness we're getting. This is a documented public API, ➢ you can't just go and ignore this parameter. Sure I can. Because the DRBG seeds from the system anyway -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Plea for a new public OpenSSL RNG API
➢ I’d like to suggest that any approach other than “immediately mix the received randomness into the RNG state” is bad. If a user does RAND_add() now, as opposed to 100 source code lines before, there may be a reason for that. I think the only way to do that in the DRBG model is to treat it as “additional input” and do a generate call. I think that would achieve the same effect, but it wouldn’t delay any possible seeding of randomness that the DRBG itself needs at some point. ➢ One “API” is how to get a reference/pointer/instance/whatever to the DRBG object responsible for the operation I’m now concerned with, and that I want to influence/improve. This would probably differ between per-SSL DRBG and per-thread DRBG, etc. I haven’t even thought about this part of the API (and I’m sure others on the team have more experience and understanding of the OpenSSL code to do it better than I would anyway). Yes, it is separate. But I want to make sure that if we are doing a comprehensive RAND overhaul that this is included in the requirements. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Plea for a new public OpenSSL RNG API
➢ IMHO this interface is a way for the user to improve the quality of the randomness it would get from the given RNG, *not* to replace (or diminish) its other sources. My proposal is to abolish this parameter, especially since now it is simply ignored (and IMHO – for a good reason). We cannot do this in a minor release; we have to wait until 1.2 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Plea for a new public OpenSSL RNG API
On 08/29/2017 01:50 PM, Blumenthal, Uri - 0553 - MITLL wrote: > IMHO this interface is a way for the user to improve the quality of the > randomness it would get from the given RNG, *not* to replace (or diminish) > its other sources. My proposal is to abolish this parameter, especially since > now it is simply ignored (and IMHO – for a good reason). That's a fine proposal ... it just can't be implemented until a major release boundary, when our ABI stability policy permits such breaking changes. -Ben -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Plea for a new public OpenSSL RNG API
➢ An other problem with the current implemenation is that the ➢ randomness parameter that's now given to RAND_add() is just ➢ ignored, it assumes it's the same as the length. For what it’s worth, this was done deliberately, make RAND_add and RAND_seed equivalent. I am skeptical of the ability to get that estimate correct. Someone on GH there is a conversation thread about turning that into a percentage, which seems like the best thing to do for any new API. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Plea for a new public OpenSSL RNG API
Could you please be more specific wrt. DRBG organization that in your opinion could impact the UI? From your use-case: you want to add entropy into a specific DRBG. You want to push it, as opposed to the DRBG “pull when needed” model. That’s an additional API. Also from your use-case: you want to specify which DRBG instance gets that entropy. If we move to a pair per thread, as opposed to one per SSL and two in the global space, how do we make sure that API still works and does the right thing. Does that makes sense, and does it answer your question? -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] How to use BIO_do_connect(), blocking and non-blocking with timeout, coping with errors
Getting the client connect right appears surprisingly messy when one needs to cope with all kinds of network error situations including domain name resolution issues and temporarily unreachable servers. Both indefinitely blocking and non-blocking behavior (i.e., connection attempts with and without a timeout) should be supported. It is a complicated issue and hard to get right for all definitions of right for all applications ☺ A set of API’s that set up all the TLS “metadata”, and took a connected socket might be a way through the maze. For example: SSL *SSL_connection(int socket, const char *servername, …whatever…) -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Plea for a new public OpenSSL RNG API
dev asap. If there are problems with it we can always revert it before it makes it into a release. Someone on the OMC called that “flip-flopping” and seemed to be against this kind of thing. If we are going to have an additional API, then we should at least see a draft of the header file first. Keep in mind that the current DRBG organization might change, and we don’t want to lose that freedom. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] CVE 2017-3735 OOB read
From https://www.openssl.org/news/secadv/20170828.txt OpenSSL Security Advisory [28 Aug 2017] Malformed X.509 IPAdressFamily could cause OOB read (CVE-2017-3735) === Severity: Low If an X.509 certificate has a malformed IPAddressFamily extension, OpenSSL could do a one-byte buffer overread. The most likely result would be an erroneous display of the certificate in text format. As this is a low severity fix, no release is being made. The fix can be found in the source repository (1.0.2, 1.1.0, and master branches); see https://github.com/openssl/openssl/pull/4276. This bug has been present since 2006. This issue was found by Google's OSS-Fuzz project on August 22. The fix was developed by Rich Salz of the OpenSSL development team. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Reseeding at fork time
For those interested, there is a lot of discussion going on over at https://github.com/openssl/openssl/pull/4239 I consider it bad that the conversation is happening there, not here, but so it goes. If you don’t have a GitHub account and wish to post, forward to me and I will post it for you. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
➢ Even opaque objects usually have some public interface. I think exposing RAND_add_ex() would be a good idea for 1.1..1, and it’s likely to serve as an acceptable “live forever” API. That’s my point. API decisions live forever. Suppose we move around the DRBG’s so that they are per-thread, or per-SSL_CTX or per-SSL object? Will that API still work? Or will we need a A “RAND_ex_ex” function? We don’t have even consensus on when and how to reseed. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
>This is why I want to add things like that by default in the >additional data. On reseed or generate? -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
>I personally see no harm if these RNG objects are made available to > applications that need/use them But decisions like this live forever. It is therefore VERY important to spend time thinking about what becomes part of the public API and what remains hidden so that we can change things later when we have a better understanding. This concept is new to OpenSSL :) But we just put out a 1.1.0 release that made things opaque, so it’s more fresh in the minds of at least some of the dev team. Personally, since DRBG is new in 1.1.1 I would be quite happy if we didn’t expose anything public until the release after that. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
>An idea that I had was to default to reseed on fork if we know we >have a working syscall. Or /dev device too? -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
Okay: https://github.com/openssl/openssl/pull/4239 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
We should think carefully about what API’s we are exposing, and might want to wait for 1.1.2 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
Is this new RNG object available to user programs, or do they need to reinvent the wheel even though they definitely link against the OpenSSL library? You don’t have to re-invent the wheel, but you might have to modify the source ☺ Did you read the blog posting? What wasn’t clear? -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
➢ But I’d like the development team to comment on (and ideally – accept) my request to add RAND_add() method to the RNG that is used in generation of private keys. Well, I’ve been thinking about this for a bit, since you first raised it. I am still not sure of the need. And as the blog post says, we’re not convinced that the current DRBG arrangement is something that will never change. But I think a new API, RAND_add_ex that took a flag that had values like RAND_ADD_GLOBAL, RAND_ADD_LOCAL, RAND_ADD_PRIVATE, RAND_LOCAL_PRIVATE indicating which to seed. Thoughts? -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
The problem with /dev/urandom will go away sooner or later. All major platforms either have a CPRNG syscall for years or introduced one recently. BSD has getentropy(2) for a while, Windows has CryptGenRandom() and Linux has getrandom(2) since Kernel 3.2 and glibc 2.15. Agreed. And when we can make –with-rand-seed=syscall the default, then it will be a happier place ☺ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
It seems to me this all depends on the order of things you do to create a daemon. You could make sure the RNG is inited, chroot, and then fork for instance. And I suspect there are actually programs that do it in that order. Yes. I think the safest thing is for us to not change the default. Programs that know they are going to fork can do the right/safe thing. It would be nicer if we could automatically always do the right thing, but I don’t think it’s possible. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
\ > somewhere someone is. And then it’s not about just reseeding, but > what about when (if) we add other things, like whether or not the > secure arena gets zero’d in a child? It's difficult to think of what circumstances this might break existing code? What scenario did you have in mind? As excerpted above in my post. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] afalg with OpenSSL 1.1.0f 25 May 2017
Hi Matt,
Thanks, I could find that the /usr/include/linux/version.h has #define
LINUX_VERSION_CODE 199168 for my booted kernel 4.9.37. Which is why I see the
following warnings also:
gcc -Iinclude -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM
-DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM
-DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM
-DOPENSSLDIR="\"/usr/local/ssl\""
-DENGINESDIR="\"/usr/local/lib64/engines-1.1\"" -Wall -O3 -pthread -m64
-DL_ENDIAN -Wa,--noexecstack -fPIC -DOPENSSL_USE_NODELETE -MMD -MF
engines/afalg/e_afalg.d.tmp -MT engines/afalg/e_afalg.o -c -o
engines/afalg/e_afalg.o engines/afalg/e_afalg.c
engines/afalg/e_afalg.c:30:4: warning: #warning "AFALG ENGINE requires Kernel
Headers >= 4.1.0" [-Wcpp]
# warning "AFALG ENGINE requires Kernel Headers >= 4.1.0"
^
engines/afalg/e_afalg.c:31:4: warning: #warning "Skipping Compilation of AFALG
engine" [-Wcpp]
# warning "Skipping Compilation of AFALG engine"
I will fix this problem now by having proper setup. Will update if I face any
more issues.
Thanks
Jitendra
On Wed, 8/16/17, Jitendra Lulla <lull...@yahoo.com> wrote:
Subject: Re: afalg with OpenSSL 1.1.0f 25 May 2017
To: "openssl-dev@openssl.org" <openssl-dev@openssl.org>, "Matt Caswell"
<m...@openssl.org>
Cc: "Jitendra Lulla" <lull...@yahoo.com>
Date: Wednesday, August 16, 2017, 6:30 AM
Hi Matt,
I have linux 4.9.37 on RHEL7.3.
[root@localhost
jlulla]# uname -a
Linux localhost.localdomain 4.9.37 #1
SMP Fri Jul 21 04:52:46 PDT 2017 x86_64 x86_64 x86_64
GNU/Linux
[root@localhost
test]# OPENSSL_ENGINES=../engines/afalg
../util/shlib_wrap.sh ./afalgtest
AFALG not supported - skipping AFALG
tests
PASS
[root@localhost
test]#
I am getting here:
# if LINUX_VERSION_CODE <=
KERNEL_VERSION(K_MAJ, K_MIN1, K_MIN2)
/*
* If we get here then it looks like
there is a mismatch between the linux
* headers and the actual kernel
version, so we have tried to compile with
* afalg support, but then skipped it
in e_afalg.c. As far as this test is
* concerned we behave as if we had
been configured without support
*/
# define OPENSSL_NO_AFALGENG
# endif
Following is the value for
KERNEL_VERSION for me:
[root@localhost
jlulla]# ./kernelversion (program at the bottom of this
mail)
KERNEL_VERSION: 262400
LINUX_VERSION_CODE 199168
condition:1
Where should I look to fix it?
Thanks
Jitrendra
[root@localhost
jlulla]# cat kernelversion.c
#define LINUX_VERSION_CODE 199168
#define KERNEL_VERSION(a,b,c) (((a)
<< 16) + ((b) << 8) + (c))
#define RHEL_MAJOR 7
#define RHEL_MINOR 3
#define RHEL_RELEASE_VERSION(a,b) (((a)
<< 8) + (b))
#define RHEL_RELEASE_CODE 1795
#define RHEL_RELEASE "514"
# define K_MAJ 4
# define K_MIN1 1
# define K_MIN2 0
#include
int main()
{
printf("KERNEL_VERSION: %d\n", KERNEL_VERSION(K_MAJ,
K_MIN1, K_MIN2));
printf("LINUX_VERSION_CODE %d\n", LINUX_VERSION_CODE);
printf("condition:%d\n",
(LINUX_VERSION_CODE <= KERNEL_VERSION(K_MAJ, K_MIN1,
K_MIN2)));
}
On Mon, 8/14/17, Matt Caswell <m...@openssl.org>
wrote:
Subject: Re: afalg with OpenSSL 1.1.0f
25 May 2017
To: "openssl-dev@openssl.org"
<openssl-dev@openssl.org>
Cc: "Jitendra Lulla" <lull...@yahoo.com>
Date: Monday, August 14, 2017, 3:44
PM
Comments inserted.
On 14/08/17 08:20, Jitendra
Lulla wrote:
> Hi,
>
> I am trying to use afalg on
Linux
4.9.37 with OpenSSL 1.1.0f.
>
> I am facing 2 issues:
>
> ONE: when I issue the speed
command, I
see the following:
>
> [root@localhost
apps]# ./openssl speed -evp
aes-128-cbc -engine afalg
> invalid engine "afalg"
>
139853452924736:error:2506406A:DSO support
routines:dlfcn_bind_func:could not
bind to the requested
symbol
name:crypto/dso/dso_dlfcn.c:178:symname(bind_engine):
/usr/local/lib64/engines-1.1/afalg.so:
undefined symbol:
bind_engine
>
139853452924736:error:2506C06A:DSO
support
routines:DSO_bind_func:could not bind
to the requested
symbol name:crypto/dso/dso_lib.c:185:
>
139853452924736:error:260B6068:engine
routines:dynamic_load:DSO
failure:crypto/engine/eng_dyn.c:427:
>
139853452924736:error:2606A074:engine
routines:ENGINE_by_id:no such
engine:crypto/engine/eng_list.c:339:id=afalg
>
139853452924736:error:25066067:DS
>
Re: [openssl-dev] afalg with OpenSSL 1.1.0f 25 May 2017
Hi Matt,
I have linux 4.9.37 on RHEL7.3.
[root@localhost jlulla]# uname -a
Linux localhost.localdomain 4.9.37 #1 SMP Fri Jul 21 04:52:46 PDT 2017 x86_64
x86_64 x86_64 GNU/Linux
[root@localhost test]# OPENSSL_ENGINES=../engines/afalg ../util/shlib_wrap.sh
./afalgtest
AFALG not supported - skipping AFALG tests
PASS
[root@localhost test]#
I am getting here:
# if LINUX_VERSION_CODE <= KERNEL_VERSION(K_MAJ, K_MIN1, K_MIN2)
/*
* If we get here then it looks like there is a mismatch between the linux
* headers and the actual kernel version, so we have tried to compile with
* afalg support, but then skipped it in e_afalg.c. As far as this test is
* concerned we behave as if we had been configured without support
*/
# define OPENSSL_NO_AFALGENG
# endif
Following is the value for KERNEL_VERSION for me:
[root@localhost jlulla]# ./kernelversion (program at the bottom of this mail)
KERNEL_VERSION: 262400
LINUX_VERSION_CODE 199168
condition:1
Where should I look to fix it?
Thanks
Jitrendra
[root@localhost jlulla]# cat kernelversion.c
#define LINUX_VERSION_CODE 199168
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
#define RHEL_MAJOR 7
#define RHEL_MINOR 3
#define RHEL_RELEASE_VERSION(a,b) (((a) << 8) + (b))
#define RHEL_RELEASE_CODE 1795
#define RHEL_RELEASE "514"
# define K_MAJ 4
# define K_MIN1 1
# define K_MIN2 0
#include
int main()
{
printf("KERNEL_VERSION: %d\n", KERNEL_VERSION(K_MAJ, K_MIN1, K_MIN2));
printf("LINUX_VERSION_CODE %d\n", LINUX_VERSION_CODE);
printf("condition:%d\n",
(LINUX_VERSION_CODE <= KERNEL_VERSION(K_MAJ, K_MIN1,
K_MIN2)));
}
On Mon, 8/14/17, Matt Caswell <m...@openssl.org> wrote:
Subject: Re: afalg with OpenSSL 1.1.0f 25 May 2017
To: "openssl-dev@openssl.org" <openssl-dev@openssl.org>
Cc: "Jitendra Lulla" <lull...@yahoo.com>
Date: Monday, August 14, 2017, 3:44 PM
Comments inserted.
On 14/08/17 08:20, Jitendra
Lulla wrote:
> Hi,
>
> I am trying to use afalg on Linux
4.9.37 with OpenSSL 1.1.0f.
>
> I am facing 2 issues:
>
> ONE: when I issue the speed command, I
see the following:
>
> [root@localhost
apps]# ./openssl speed -evp aes-128-cbc -engine afalg
> invalid engine "afalg"
> 139853452924736:error:2506406A:DSO support
routines:dlfcn_bind_func:could not bind to the requested
symbol name:crypto/dso/dso_dlfcn.c:178:symname(bind_engine):
/usr/local/lib64/engines-1.1/afalg.so: undefined symbol:
bind_engine
>
139853452924736:error:2506C06A:DSO support
routines:DSO_bind_func:could not bind to the requested
symbol name:crypto/dso/dso_lib.c:185:
>
139853452924736:error:260B6068:engine
routines:dynamic_load:DSO
failure:crypto/engine/eng_dyn.c:427:
>
139853452924736:error:2606A074:engine
routines:ENGINE_by_id:no such
engine:crypto/engine/eng_list.c:339:id=afalg
> 139853452924736:error:25066067:DS
>
>
> nm afalg.so doesn't show
bind_engine
>
Assuming
you have already successfully built OpenSSL using
"make", from
the "test"
subdir of the directory where you downloaded the source,
what
happens if you execute:
OPENSSL_ENGINES=../engines/afalg
../util/shlib_wrap.sh ./afalgtest
Another thing to try is (from the top level
source dir)
touch
engines/afalg/e_afalg.c
make
Check to see if there are any
warnings generated during the compilation
of
the engine.
>
> When I modify the openssl.cnf file with
the engine name and the CIPHERS, still I dont get it
working. The command output and the change in the
openssl.cnf pasted at the end of the mail.
>
>
> TWO: I had to create a softlink to
libcrypto.so.1.1 and libssl.so.1.1 like the following to
make openssl command work:
> ln -s
/usr/local/lib64/libssl.so.1.1 /lib64/libssl.so.1.1
> ln -s /usr/local/lib64/libcrypto.so.1.1
/lib64/libcrypto.so.1.1
>
> Is creating the softlinks a known issue
and will be fixed?
No, this will not be
fixed and may not be the most appropriate thing to
do on all systems.
Matt
>
> I have pasted the
complete information about the OS/distro environment and
installation commands I ran at the bottom.
> Could you please suggest what wrong I am
doing to make afalg work.
>
> Thanks
> Jitendra
Lulla
>
> ====
>
>
> BEFORE INSTALLATION:
>
> [root@localhost
jlulla]# rpm -qa |grep openssl
>
openssl-1.0.1e-60.el7.x86_64
>
openssl-devel-1.0.1e-60.el7.x86_64
>
openssl-libs-1.0.1e-60.el7.x86_64
>
> [root@localhost
jlulla]# openssl version
> OpenSSL
1.0.1e-fips 11 Feb 2013
>
>
>
> PLEASE SEE FROM HERE PLEASE SEE FROM HERE
PLEASE SEE FROM HERE
>
Re: [openssl-dev] Work on a new RNG for OpenSSL
And this is a very good answer. Perhaps this guidance deserves being documented somewhere besides this mailing list? Something along the lines of It is documented in the RAND_add manpage. ➢ I’m not sure I agree here. What effort are you talking about? In order to select an order in which available sources are queried, the developers had to think (hopefully :). Those thought could be documented in a few lines of text. And what would be the point? Why should someone trust the documentation, which can get out of date, more than the source? ➢ So while the team clearly has the right to make changes (especially before the interface became public ;), but I’d rather that such changes are guided by an informed consent from the public (such as yours truly ;). We aren’t cutting off any avenues of participation. Email discussion and pull requests are always welcome. But yes, the barrier to useful participation is that someone has to first read and understand the source. ➢ I think it is *imperative* for a user to be able to RAND_add() to the DRBG that gnerates private keys. I cannot emphasize enough how critical this is. I am curious to know your justification for this. It seems to me that if you accept the DRBG document, which we do, then the way we do the seeding is fine. If you don’t accept the document, then modify the source. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
>>> 3. What should I do if I want a given source to be used in addition to the >>> other sources, regardless of whether openssl thinks it got “enough bits” of >>> randomness or not? >> Modify the source :) >Very bad answer. And also a wrong one. Your application can always call RAND_add(). Sorry for mistake. > I have no problem reading the source code. I do have a problem with (a) > important decisions like this not “formalized” and documented, and (b) > mechanisms to tune the RNG seeding not provided and clearly and > comprehensively documented. This is a mostly volunteer open source project. We are unlikely to commit to something that requires so much effort when, frankly, most of the consumers aren’t interested, or qualified, to make an assessment. I am sorry if that sounds obnoxious or conceited. It shouldn’t; there are many things that I know I’m not qualified to comment on :) And also, we reserve the right to make changes. I expect that the FIPS project, just starting, will be of interest to you. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
> 1. What’s the default if “with-rand-seed” was not provided? All of the listed > supported types? None of them? Some of them…? As the first bullet says, it’s “os”. As for the second part of your question, it is deliberately not answered. If you care, you’ll have to read the source. (It’s clean and easy to do so, now.) We’re not documenting everything. >2. What is the order in which the seed sources are tried (both when >“with-random-seed” was and was not given)? Read the source. > 3. What should I do if I want a given source to be used in addition to the > other sources, regardless of whether openssl thinks it got “enough bits” of > randomness or not? Modify the source :) For a few reasons, we’re deliberately not documenting all the details. Interested parties will have to read the source. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
Thanks everyone for the discussion (mainly in June) about this. There’s a blog post describing what we’ve done for the 1.1.1 release: https://www.openssl.org/blog/blog/2017/08/12/random/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] afalg with OpenSSL 1.1.0f 25 May 2017
Hi, I am trying to use afalg on Linux 4.9.37 with OpenSSL 1.1.0f. I am facing 2 issues: ONE: when I issue the speed command, I see the following: [root@localhost apps]# ./openssl speed -evp aes-128-cbc -engine afalg invalid engine "afalg" 139853452924736:error:2506406A:DSO support routines:dlfcn_bind_func:could not bind to the requested symbol name:crypto/dso/dso_dlfcn.c:178:symname(bind_engine): /usr/local/lib64/engines-1.1/afalg.so: undefined symbol: bind_engine 139853452924736:error:2506C06A:DSO support routines:DSO_bind_func:could not bind to the requested symbol name:crypto/dso/dso_lib.c:185: 139853452924736:error:260B6068:engine routines:dynamic_load:DSO failure:crypto/engine/eng_dyn.c:427: 139853452924736:error:2606A074:engine routines:ENGINE_by_id:no such engine:crypto/engine/eng_list.c:339:id=afalg 139853452924736:error:25066067:DS nm afalg.so doesn't show bind_engine When I modify the openssl.cnf file with the engine name and the CIPHERS, still I dont get it working. The command output and the change in the openssl.cnf pasted at the end of the mail. TWO: I had to create a softlink to libcrypto.so.1.1 and libssl.so.1.1 like the following to make openssl command work: ln -s /usr/local/lib64/libssl.so.1.1 /lib64/libssl.so.1.1 ln -s /usr/local/lib64/libcrypto.so.1.1 /lib64/libcrypto.so.1.1 Is creating the softlinks a known issue and will be fixed? I have pasted the complete information about the OS/distro environment and installation commands I ran at the bottom. Could you please suggest what wrong I am doing to make afalg work. Thanks Jitendra Lulla BEFORE INSTALLATION: [root@localhost jlulla]# rpm -qa |grep openssl openssl-1.0.1e-60.el7.x86_64 openssl-devel-1.0.1e-60.el7.x86_64 openssl-libs-1.0.1e-60.el7.x86_64 [root@localhost jlulla]# openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 PLEASE SEE FROM HERE PLEASE SEE FROM HERE PLEASE SEE FROM HERE STEP 1 : SOURCE TAKEN FROM https://www.openssl.org/source/openssl-1.1.0f.tar.gz 2017-May-25 13:09:51 [root@localhost jlulla]# uname -a Linux localhost.localdomain 4.9.37 #1 SMP Fri Jul 21 04:52:46 PDT 2017 x86_64 x86_64 x86_64 GNU/Linux [root@localhost jlulla]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.3 (Maipo) [root@localhost openssl-1.1.0f]# pwd /home/jlulla/openssl-1.1.0f STEP 2: [root@localhost openssl-1.1.0f]# ./config shared enable-engine enable-dso enable-afalgeng Operating system: x86_64-whatever-linux2 Configuring for linux-x86_64 Configuring OpenSSL version 1.1.0f (0x1010006fL) no-asan[default] OPENSSL_NO_ASAN no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG no-crypto-mdebug-backtrace [default] OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 no-egd [default] OPENSSL_NO_EGD no-fuzz-afl[default] OPENSSL_NO_FUZZ_AFL no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER no-heartbeats [default] OPENSSL_NO_HEARTBEATS no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-msan[default] OPENSSL_NO_MSAN no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-sctp[default] OPENSSL_NO_SCTP no-ssl-trace[default] OPENSSL_NO_SSL_TRACE no-ssl3[default] OPENSSL_NO_SSL3 no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD no-ubsan[default] OPENSSL_NO_UBSAN no-unit-test[default] OPENSSL_NO_UNIT_TEST no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS no-zlib[default] no-zlib-dynamic [default] Configuring for linux-x86_64 CC=gcc CFLAG=-Wall -O3 -pthread -m64 -DL_ENDIAN -Wa,--noexecstack SHARED_CFLAG =-fPIC -DOPENSSL_USE_NODELETE DEFINES =DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM PADLOCK_ASM POLY1305_ASM LFLAG= PLIB_LFLAG= EX_LIBS =-ldl APPS_OBJ = CPUID_OBJ=x86_64cpuid.o UPLINK_OBJ= BN_ASM=asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o EC_ASM=ecp_nistz256.o ecp_nistz256-x86_64.o DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o BF_ENC=bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4-x86_64.o rc4-md5-x86_64.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM =md5-x86_64.o SHA1_OBJ_ASM =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o RMD160_OBJ_ASM= CMLL_ENC =cmll-x86_64.o cmll_misc.o MODES_OBJ=ghash-x86_64.o aesni-gcm-x86_64.o PADLOCK_OBJ =e_padlock-x86_64.o CHACHA_ENC=chacha-x86_64.o POLY1305_OBJ =poly1305-x86_64.o
Re: [openssl-dev] draft-21 status
On 08/09/2017 08:03 AM, Loganaden Velvindron wrote: > Dear OpenSSL folks, > > I was wondering if there is a branch for draft-21 ? > draft-21 support is on master at the moment; there's no need for a separate branch until there is a draft-22 document to support. -Ben -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] FW: Code health tuesday is back!
A reminder: After a short summer vacation, our biweekly code health Tuesday is back! Our topic this time is … documentation. There have been many updates to the manpages in the past few weeks, typo fixes, additional clarifications, and so on. We hope that folks will be emboldened to help fill in the gaps, but any PR to make things better will help. Please submit your fixes by Tuesday; if you can’t add a label, put ‘code health’ somewhere in the commit message. Please have a CLA on file; if your commit is trivial and not copyrightable, put “CLA: trivial” in the commit message. If you have a whole bunch of trivial fixes, put them in one PR (separate commits if you want). Make sure any changes pass find-doc-nits (a script in util). You can also use that script to list places where documentation is missing: ; ./util/find-doc-nits -u | fgrep '#' # Found 4373 in util/libcrypto.num # Found 1724 missing from util/libcrypto.num # Found 464 in util/libssl.num # Found 64 missing from util/libssl.num # Checking macros (approximate) # Found 246 macros missing (not all should be documnted) Thanks for all your help in improving OpenSSL! -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Current master fails to build
> After that is fixed, test 80-test_new_ssl.t fails (wstat 256, 0x100). Do you have core file? The failure is not repeatable, at least on my system :( -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Code health tuesday is back!
After a short summer vacation, our biweekly code health Tuesday is back! Our topic this time is ... documentation. There have been many updates to the manpages in the past few weeks, typo fixes, additional clarifications, and so on. We hope that folks will be emboldened to help fill in the gaps, but any PR to make things better will help. Please submit your fixes by Tuesday; if you can't add a label, put 'code health' somewhere in the commit message. Please have a CLA onfile; if your commit is trivial and not copyrightable, put "CLA: trivial" in the commit message. If you have a whole bunch of trivial fixes, put them in one PR (separate commits if you want). Make sure any changes pass find-doc-nits (a script in util). You can also use that script to list places where documentation is missing: ; ./util/find-doc-nits -u | fgrep '#' # Found 4373 in util/libcrypto.num # Found 1724 missing from util/libcrypto.num # Found 464 in util/libssl.num # Found 64 missing from util/libssl.num # Checking macros (approximate) # Found 246 macros missing (not all should be documnted) Thanks for all your help in improving OpenSSL! -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Build issue
On 07/28/2017 01:22 AM, Matthew Stickney wrote: > With a make distclean, ./config, make depend (didn't appear to do > anything), and a make, I'm getting the essentially the same thing: > > Error: _num does not have a number assigned > /usr/bin/perl ./util/mkrc.pl libcrypto-1_1-x64.dll | windres > --target=pe-x86-64 > -o rc.o > LD_LIBRARY_PATH=: gcc -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS > -DOPENSSL_NO_STATIC > _ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT > -DOPENSSL_BN_ASM > _MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM > -DMD > 5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM > -DPADLOCK > _ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" > -DENGINESDIR="/usr/local/lib/e > ngines-1_1" -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall > -O3 > -D_MT -D_WINDLL -static-libgcc -shared -Wl,-Bsymbolic > -Wl,--out-implib,libcrypt > o.dll.a crypto.def rc.o -o libcrypto-1_1-x64.dll -Wl,--whole-archive > libcrypto.a > -Wl,--no-whole-archive -lws2_32 -lgdi32 -lcrypt32 > Cannot export MD2: symbol not defined > Cannot export MD2_Final: symbol not defined > Cannot export MD2_Init: symbol not defined > Cannot export MD2_Update: symbol not defined > Cannot export MD2_options: symbol not defined > Cannot export RC5_32_cbc_encrypt: symbol not defined > Cannot export RC5_32_cfb64_encrypt: symbol not defined > Cannot export RC5_32_decrypt: symbol not defined > Cannot export RC5_32_ecb_encrypt: symbol not defined > Cannot export RC5_32_encrypt: symbol not defined > Cannot export RC5_32_ofb64_encrypt: symbol not defined > Cannot export RC5_32_set_key: symbol not defined > collect2.exe: error: ld returned 1 exit status > MD2 and RC5 are disabled by default, so it is expected that they will not be defined. It is hard to say whether those messages are the source of the error exit status or just warnings, though. It's certainly plausible that there are further mkdef.pl issues responsible, though. Since mkdef.pl generates the crypto.def file referenced on your link line, maybe you could post that somewhere and link to it? (mkdef.pl can also be used to generate .map files, but it seems like the .def file is the relevant one at the moment.) But I may have to defer to Richard for the workings of mkdef.pl itself... -Ben -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Build issue
On 07/25/2017 07:49 PM, Matthew Stickney wrote: > Possibly. The original errors and hanging perl process have been > replaced with an enormous number of "undefined reference" errors. For > example: > libssl.a(tls_srp.o):tls_srp.c:(.text+0xc4c): undefined reference to `BN_ucmp' > libssl.a(tls_srp.o):tls_srp.c:(.text+0xd45): undefined reference to > `OPENSSL_cleanse' > libssl.a(tls_srp.o):tls_srp.c:(.text+0xd5f): undefined reference to > `SRP_Calc_A' > collect2.exe: error: ld returned 1 exit status > > I don't know enough about the build system to know whether the > mkdef.pl change might be responsible for this, or whether this is a > separate issue. To follow up on my previous post, the configure line > was indeed "./config", and this is commit 1843787173. Any other data > that I should collect? > Hmm, all of the listed examples are for things in libssl failing to find symbols from libcrypto, which perhaps suggests a link line ordering issue. Can you paste the actual linker invocation that is failing? -Ben -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Fix a dead lock of async engine.
On 07/26/2017 08:15 AM, Emeric Brun wrote: > Hi All, > > This bug also affects the 1.1.0 > Are you able to submit the patch as a github pull request? That would be the preferred form, as it enables some automation that we have for CLA checks and CI. -Ben -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Build issue
On 07/25/2017 01:52 PM, Matthew Stickney wrote: > I've been trying to build OpenSSL to work on a new feature, but I've > had problems with the build hanging. I'm building on Windows 10 with > mingw-w64 under msys2; perl is v5.24, and I installed the > Text::Template module from CPAN. > You did not show the config line used, which is perhaps relevant. Also, presumably the perl is the msys perl, but please confirm -- it must be "matching" in order for things to work. -Ben -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
