Date: Sat, 12 Dec 2020 16:57:08 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl Message-ID: <20201213005708.GU31099@funkthat.com> In-Reply-To: <813a04a4-e07a-9608-40a5-cc8e339351eb@FreeBSD.org> References: <20201209230300.03251CA1@freefall.freebsd.org> <20201211064628.GM31099@funkthat.com> <813a04a4-e07a-9608-40a5-cc8e339351eb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote this message on Sat, Dec 12, 2020 at 11:40 -0800: > 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 I went back to the original PR that rewrote /dev/crypto: https://github.com/openssl/openssl/pull/3744 The PR was submitted in June 2017, and they tested on FreeBSD 8.4-R, which had support end on June 2015. Even back in 2017, it was easy enough w/ VMs and cloud compute to spin up a modern, supported FreeBSD box. Yes, it's good that it's now getting fixed, 3 years after it was broken. If FreeBSD is going to continue to use OpenSSL, better testing needs to be done to figure out such breakage earliers, and how to not have them go undetected for so long. > 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 I'll note that this article is more for a developer than the maintainer of an OS. When FreeBSD has 5 year support cycles, things are slightly different, otherwise I agree that the article is good advice (from my brief reading/looking over). > > 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. In the case of mixed 1.1.1 and 3.0.0, that should just be disallowed. Though importing 3.0.0 doesn't solve the issue if 1.1.1 has a security problem... Because the security problem in 1.1.1 will still need to be addressed to deal w/ all the applications that are linked against it.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201213005708.GU31099>