From owner-freebsd-security@freebsd.org Fri Dec 11 20:38:27 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 316A44BA2F8 for ; Fri, 11 Dec 2020 20:38:27 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ct2g5756tz4rk8 for ; Fri, 11 Dec 2020 20:38:25 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BBKcJsr014096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 11 Dec 2020 15:38:23 -0500 Date: Fri, 11 Dec 2020 12:38:18 -0800 From: Benjamin Kaduk To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl Message-ID: <20201211203818.GL64351@kduck.mit.edu> References: <20201209230300.03251CA1@freefall.freebsd.org> <20201211064628.GM31099@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201211064628.GM31099@funkthat.com> X-Rspamd-Queue-Id: 4Ct2g5756tz4rk8 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kaduk@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=kaduk@mit.edu X-Spamd-Result: default: False [-0.33 / 15.00]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[18.9.28.11:from]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[mit.edu]; NEURAL_HAM_SHORT(-0.03)[-0.035]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-security]; RECEIVED_SPAMHAUS_PBL(0.00)[24.16.140.251:received] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 20:38:27 -0000 Hi John-Mark, 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? 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 https://github.com/openssl/openssl/pull/13468 up waiting for review. 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. > 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 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. -Ben