Date: Fri, 11 Dec 2020 14:35:42 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Benjamin Kaduk <kaduk@mit.edu> Cc: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl Message-ID: <20201211223542.GQ31099@funkthat.com> In-Reply-To: <20201211203818.GL64351@kduck.mit.edu> References: <20201209230300.03251CA1@freefall.freebsd.org> <20201211064628.GM31099@funkthat.com> <20201211203818.GL64351@kduck.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Benjamin Kaduk wrote this message on Fri, Dec 11, 2020 at 12:38 -0800: > 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? Software is not a stand still, just because in the past we didn't find anything, doesn't mean we won't find something this time. > 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 No, but it demonstrates the amount of work that the OpenSSL devs are putting in to supporting FreeBSD. It's one thing to say, we're not going to support /dev/crypto anymore and stop compiling it on FreeBSD, it's another to take known working software and intentionally break it w/o evaluating it's impact upon their "supported" platforms. OpenSSL chose to do the later... > https://github.com/openssl/openssl/pull/13468 up waiting for review. Why is FreeBSD reacting to these problems? Why didn't OpenSSL devs drop a mail to FreeBSD -security saying, btw, we've changed X, and we know it'll break your code, so heads up if anyone wants to fix it, please submit patches, otherwise in a few weeks we'll disable building support for it on FreeBSD. If they're not regularly running and testing code on FreeBSD (or is actively working w/ a person to do such a thing), can we really say that OpenSSL supports FreeBSD? > 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. Sounds like you need to get a QAT system or other accelerator board for testing then. There are a new class of crypto accelerators that make this a viable option again, so I dispute your definition of devcrypto not being useful. > > 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 Until the OpenSSL project changes it, we have to operate under the assumption that the date will not change, and make plans to deal w/ OpenSSL 1.1.1 on 13-current for years after OpenSSL stops supporting it. > 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. -- 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?20201211223542.GQ31099>