Date: Fri, 11 Dec 2020 20:37:59 -0800 From: Benjamin Kaduk <kaduk@mit.edu> To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl Message-ID: <20201212043759.GN64351@kduck.mit.edu> In-Reply-To: <20201211223542.GQ31099@funkthat.com> References: <20201209230300.03251CA1@freefall.freebsd.org> <20201211064628.GM31099@funkthat.com> <20201211203818.GL64351@kduck.mit.edu> <20201211223542.GQ31099@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 11, 2020 at 02:35:42PM -0800, John-Mark Gurney wrote: > 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. Sure. I was just hoping that you might have some thoughts about what had changed, since you were bringing it up again, though I don't mind asking an open question to the list. > > 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... With all due respect, that seems to misrepresent the facts of the situation. If you consider the history at https://github.com/openssl/openssl/pull/3744 it is quite clear that the cryptodev rewrite was specifically tested on FreeBSD before it was committed. An older version, to be sure, yet we might as well be complaining about FreeBSD having changed the userspace/kernel interface rather than OpenSSL having changed its interface. (I am pretty sure that I pointed out to levitte at the time that it was an old version, but I didn't feel a need to repeat the testing locally because FreeBSD is known for its backward compatibility. I don't have that mail on this system, though.) > > 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? Um, hello? I'm an OpenSSL committer and I regularly build and test the OpenSSL code on FreeBSD. Not the devcrypto engine, obviously, given the rest of this thread, but the rest of it. Having recently learned that my assumption about the devcrypto engine was misguided, I can start testing that, too. There's also been some recent work from David Carlier to help bring support for some of the more advanced features to FreeBSD as well. If you want examples of upstream proactively keeping up FreeBSD support, I offer: https://github.com/openssl/openssl/pull/12887 https://github.com/openssl/openssl/pull/11797 https://github.com/openssl/openssl/pull/8509 and that's the only instances of FreeBSD-specific breakage (other than devcrypto) that I can recall. The "new" (several years old, at this point) mandatory code-review policy seems to be doing its job, and the quality of new code is generally pretty good. > > 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. I said that I "didn't expect", past tense. I now know otherwise. And I don't actually need proper accelleration to test the accelleration support; just to know that it is worth doing. (Note that ENGINE itself is deprecated in 3.0.) > > > 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. Yes. I assert, as someone who (co-)maintains both the public OpenSSL and a corporate derivative, that being on our own with OpenSSL 1.1.1 is much easier than being on our own with, say, BoringSSL would be. There is risk, to be sure, and the suggestion downthread to make it a private library may well be wise, but I don't see it as catastrophic risk. -Ben > > 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?20201212043759.GN64351>