FreeBSD Security Advisories wrote this message on Wed, Dec 09, 2020 at 23:03 +0000:> versions included in FreeBSD 12.x. This vulnerability is also known to > affect OpenSSL versions included in FreeBSD 11.4. However, the OpenSSL > project is only giving patches for that version to premium support contract > holders. The FreeBSD project does not have access to these patches and > recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or leverage > up to date versions of OpenSSL in the ports/pkg system. The FreeBSD Project > may update this advisory to include FreeBSD 11.4 should patches become > publicly available.FreeBSD needs to reevaluate the continued reliance on OpenSSL for our crypto/TLS library. 1.0.2 which is in 11-stable has not had support for almost a year, and 11 is going to have almost another year of support during which time if there's another vuln, we'll again be leaving the users in a bad place. I have not heard if OpenSSL has bother to address the breakage of /dev/crypto that also recently came up, but it does appear that they are no longer a good fit for FreeBSD. Even as it stands, FreeBSD has committed to supporting 12 for close to a year longer than OpenSSL has for 1.1.1 meaning we will be in the same situation we are w/ 11 in a few years. Assuming 13 releases w/ OpenSSL, we'll be even in a worse situation than we are now. OpenSSL 3.0.0 has no support commitment announced yet, and sticking with 1.1.1 for 13 will put us even in a worse situation than we are today. What are peoples thoughts on how to address the support mismatch between FreeBSD and OpenSSL? And how to address it? IMO, FreeBSD does need to do something, and staying w/ OpenSSL does not look like a viable option. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Hi, Am 11.12.20 um 07:46 schrieb John-Mark Gurney:> > Assuming 13 releases w/ OpenSSL, we'll be even in a worse situation > than we are now. OpenSSL 3.0.0 has no support commitment announced > yet, and sticking with 1.1.1 for 13 will put us even in a worse > situation than we are today. > > What are peoples thoughts on how to address the support mismatch between > FreeBSD and OpenSSL? And how to address it? > > IMO, FreeBSD does need to do something, and staying w/ OpenSSL does > not look like a viable option. >you may install a current OpenSSL via ports if you like to. I don't see any OpenSSL fork to be more reliable than its predecessor but there has been done much work in the portstree to enable the system administrator to switch. There is not much left (if anything) to be done in FreeBSD itself regarding the standard crypto library. regards, Robert Schulze
>>>>> On Thu, 10 Dec 2020 22:46:28 -0800, John-Mark Gurney said: > > What are peoples thoughts on how to address the support mismatch between > FreeBSD and OpenSSL? And how to address it?Maybe it would help a little if the packages on pkg.FreeBSD.org all used the pkg version of OpenSSL? Currently, it looks like you have build your own ports if you want that. __Martin
Hi John-Mark, On Thu, Dec 10, 2020 at 10:46:28PM -0800, John-Mark Gurney wrote:> FreeBSD Security Advisories wrote this message on Wed, Dec 09, 2020 at 23:03 +0000: > > versions included in FreeBSD 12.x. This vulnerability is also known to > > affect OpenSSL versions included in FreeBSD 11.4. However, the OpenSSL > > project is only giving patches for that version to premium support contract > > holders. The FreeBSD project does not have access to these patches and > > recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or leverage > > up to date versions of OpenSSL in the ports/pkg system. The FreeBSD Project > > may update this advisory to include FreeBSD 11.4 should patches become > > publicly available. > > FreeBSD needs to reevaluate the continued reliance on OpenSSL for our > crypto/TLS library. 1.0.2 which is in 11-stable has not had support > for almost a year, and 11 is going to have almost another year of > support during which time if there's another vuln, we'll again be > leaving the users in a bad place.To be blunt: didn't we try reevaluating already, and come up empty? OpenSSL's 5-year support lifetime is quite generous, in my experience, and we are suffering more of a clash of release dates than a fundamental support-lifetime mismatch.> I have not heard if OpenSSL has bother to address the breakage of > /dev/crypto that also recently came up, but it does appear that they > are no longer a good fit for FreeBSD.I'm not sure why you leap from issues with the devcrypto engine to a broader "no longer a good fit" conclusion. The devcrypto engine is hardly a core piece of functionality, and jhb has https://github.com/openssl/openssl/pull/13468 up waiting for review. I regularly commit to openssl from my FreeBSD system, including the build+test cycle; the core functionality remains well-supported. To be honest, I didn't bother caring about devcrypto because I didn't expect it to be widely used, given that you have to have special hardware to overcome the hit of syscall context switching.> Even as it stands, FreeBSD has committed to supporting 12 for close > to a year longer than OpenSSL has for 1.1.1 meaning we will be in the > same situation we are w/ 11 in a few years. > > Assuming 13 releases w/ OpenSSL, we'll be even in a worse situation > than we are now. OpenSSL 3.0.0 has no support commitment announced > yet, and sticking with 1.1.1 for 13 will put us even in a worse > situation than we are today.OpenSSL 3.0.0 is not going to be LTS; I expect it to go EoL before 1.1.1 does. (And I expect 1.1.1 to be supported past 2023-09-11, though of course I do not speak for the project.) I also think that 3.0.0 is not the recommended relase for anyone who doesn't need the FIPS compatibility; there's been a substantial rearchitecture and will likely be growing pains as tend to accompany dot-zero releases.> What are peoples thoughts on how to address the support mismatch between > FreeBSD and OpenSSL? And how to address it? > > IMO, FreeBSD does need to do something, and staying w/ OpenSSL does > not look like a viable option.IMO OpenSSL 1.1.1 is generally in pretty good shape and much easier to maintain than 1.0.2 was. I have yet to see an alternative suitable for inclusion in the base system that would be more viable. -Ben
On 12/10/20 10:46 PM, John-Mark Gurney wrote:> FreeBSD Security Advisories wrote this message on Wed, Dec 09, 2020 at 23:03 +0000: >> versions included in FreeBSD 12.x. This vulnerability is also known to >> affect OpenSSL versions included in FreeBSD 11.4. However, the OpenSSL >> project is only giving patches for that version to premium support contract >> holders. The FreeBSD project does not have access to these patches and >> recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or leverage >> up to date versions of OpenSSL in the ports/pkg system. The FreeBSD Project >> may update this advisory to include FreeBSD 11.4 should patches become >> publicly available. > > FreeBSD needs to reevaluate the continued reliance on OpenSSL for our > crypto/TLS library. 1.0.2 which is in 11-stable has not had support > for almost a year, and 11 is going to have almost another year of > support during which time if there's another vuln, we'll again be > leaving the users in a bad place. > > I have not heard if OpenSSL has bother to address the breakage of > /dev/crypto that also recently came up, but it does appear that they > are no longer a good fit for FreeBSD.I think I can't disagree more. In terms of /dev/crypto, see here: https://github.com/openssl/openssl/pull/13468 Also, OpenSSL has been perfectly fine to work with in terms of upstreaming KTLS. kaduk@ is an OpenSSL committer and has been helpful with helping me find reviewers for patches when needed as well. In terms of OpenSSL vs other SSL libraries, I'll defer to this: https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html> Even as it stands, FreeBSD has committed to supporting 12 for close > to a year longer than OpenSSL has for 1.1.1 meaning we will be in the > same situation we are w/ 11 in a few years. > > Assuming 13 releases w/ OpenSSL, we'll be even in a worse situation > than we are now. OpenSSL 3.0.0 has no support commitment announced > yet, and sticking with 1.1.1 for 13 will put us even in a worse > situation than we are today. > > What are peoples thoughts on how to address the support mismatch between > FreeBSD and OpenSSL? And how to address it?I do think the support mismatch questions are still real, and I'm not sure what the best answer is. My guess is that the the delay of 3.0.0 (which I had hoped would ship in 13.0) will mean that 1.1.1's lifetime will get extended, but probably not enough to cover 13.x for 5 years. One option may be that we provide a compat openssl for 13.x that is 1.1.1 for things built on the head of the branch but actually import OpenSSL 3.0.0 into stable/13 at some point. You could do this with a shlib major version bump. It won't solve all problems if some shared library linked against 1.1.1 returns some object allocated by libssl that the application tries to use directly (and the application is linked against 3.0.0), but I'm not sure how common that situation will be in practice. OpenSSL isn't libc where you have issues with malloc/free crossing this sort of boundary. -- John Baldwin