From owner-freebsd-security@freebsd.org Sat Dec 12 03:11:18 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 80E6647DD64 for ; Sat, 12 Dec 2020 03:11:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CtCNP0BXdz3qKf for ; Sat, 12 Dec 2020 03:11:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 0BC3B7Gu090930 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 12 Dec 2020 05:11:10 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 0BC3B7Gu090930 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 0BC3B7Ph090929; Sat, 12 Dec 2020 05:11:07 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 12 Dec 2020 05:11:07 +0200 From: Konstantin Belousov To: Gordon Tetlow Cc: Benjamin Kaduk , freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl Message-ID: References: <20201209230300.03251CA1@freefall.freebsd.org> <20201211064628.GM31099@funkthat.com> <20201211203818.GL64351@kduck.mit.edu> <20201211223542.GQ31099@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4CtCNP0BXdz3qKf X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [2.33 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:d5e7:1::1:from]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_SPAM_SHORT(0.98)[0.975]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_MEDIUM(0.36)[0.357]; SPAMHAUS_ZRD(0.00)[2001:470:d5e7:1::1:from:127.0.2.255]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-security]; RCVD_COUNT_TWO(0.00)[2] 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: Sat, 12 Dec 2020 03:11:18 -0000 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.