Date: Sat, 12 Dec 2020 05:11:07 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Gordon Tetlow <gordon@tetlows.org> Cc: Benjamin Kaduk <kaduk@mit.edu>, freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl Message-ID: <X9Q0y9THs4KVHytq@kib.kiev.ua> In-Reply-To: <X9QuBdITtl4BzKgI@gmail.com> References: <20201209230300.03251CA1@freefall.freebsd.org> <20201211064628.GM31099@funkthat.com> <20201211203818.GL64351@kduck.mit.edu> <20201211223542.GQ31099@funkthat.com> <X9QuBdITtl4BzKgI@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?X9Q0y9THs4KVHytq>