Date: Fri, 11 Dec 2020 19:44:12 -0800 From: Benjamin Kaduk <kaduk@mit.edu> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Gordon Tetlow <gordon@tetlows.org>, freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl Message-ID: <20201212034412.GM64351@kduck.mit.edu> In-Reply-To: <X9Q0y9THs4KVHytq@kib.kiev.ua> References: <20201209230300.03251CA1@freefall.freebsd.org> <20201211064628.GM31099@funkthat.com> <20201211203818.GL64351@kduck.mit.edu> <20201211223542.GQ31099@funkthat.com> <X9QuBdITtl4BzKgI@gmail.com> <X9Q0y9THs4KVHytq@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 12, 2020 at 05:11:07AM +0200, Konstantin Belousov wrote: > On Fri, Dec 11, 2020 at 06:42:13PM -0800, Gordon Tetlow via freebsd-security wrote: > > 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. > > > > I welcome a reasonable alternative to be put forward, but I'm pretty > > sure there isn't one. The five year lifespan of our releases pretty much > > guarantees our crypto toolkit is going to be out of support. This is the > > reality we have signed up for. > > > > LibreSSL - 1 year lifespan of stable branch. > > BoringSSL - No guarantee of API/ABI stability. Actively tells people not > > to use it for production use cases. > > > > Anything other viable implementations I'm missing? > I believe it was discussed, but either there are some insurmountable > issues, or it was abandoned just because. > > What about making openssl private for base ? Pro is that it would be > possible to update to new major release in the midst of the stable > branch, and even keep all branches on the same release. There is no ABI > or API stability to satisfy. > > There is a technical cons argument, besides amount of work required. It > is important that private openssl libs do not leaked into user namespace > and did not clashed with openssl names from ports. Basically, I believe > this is what makes the issue hard and requires a lot of work. > > BTW, this is something where upstream OpenSSL could help. If they started > supporting mangling all exported symbols, it would make this proposal easier > up to the trivial level. There's currently support for mangling the SONAME and symbol version (https://github.com/openssl/openssl/commit/822b5e2645a99bea15329bd66c9723c7e7119cdb) but not the actual symbols themselves. Given that the exported symbols are already tracked in the ".num" files and there's perl to process them, it seems like it would not be a huge amount of work to add some mangling and emit a header with the relevant #defines ... I'm less sure of whether it would easily get accepted, though. I think the topic has come up previously but would have to dig a bit to find it. -Ben
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201212034412.GM64351>