From owner-freebsd-security@FreeBSD.ORG Wed Jun 11 13:29:41 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99D33681 for ; Wed, 11 Jun 2014 13:29:41 +0000 (UTC) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 142DE275F for ; Wed, 11 Jun 2014 13:29:40 +0000 (UTC) Received: from kgw.obluda.cz ([194.108.204.138]) by smtp1.ms.mff.cuni.cz (8.14.5/8.14.5) with ESMTP id s5BDTW60057784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Wed, 11 Jun 2014 15:29:38 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <539859BC.2050303@obluda.cz> Date: Wed, 11 Jun 2014 15:29:32 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: Ben Laurie Subject: Re: OpenSSL end of life References: <5398482C.7020406@obluda.cz> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 13:29:41 -0000 On 06/11/14 15:00, Ben Laurie: >> Some of them wish to declare lifetime of particular version at the time of >> release. It will be possible no longer as embedded OpenSSL may become >> obsolete at any time. > > This is already true, because of bugs. And, in practice, no version of > OpenSSL (or anything else, pretty much) has a lifetime such that you > can safely make a non-upgradeable product from it. Don't mix security patch and upgrade. With security patch the ABI doesn't change. So I can just replace the compiled library by the new one patched and restart the daemon (or system). With new version, the same approach is not possible. All application needs to be recompiled. And if API become changed as well, then all applications needs to be reevaluated at the source level - and modified, if necessary according API changes. We can't just blindly compile old sources against new OpenSSL wishing for security, isn't it ? Even if the source will compile against new API, it doesn't mean it will work as expected - and - it's still secure. > Alternatively, can 9.3 not upgrade to a newer OpenSSL? Upgraded ? Yes, but upgraded to another version than 9.3 9.3 can be patched during it's lifetime, but 9.3-pX and 9.3-pY needs to be binary compatible. If it is not compatible, then it's no 9.3 anymore. > One modification I'd be prepared to contemplate is that 1.0.1 (for > example) is supported for some known period of time, even if it should > be EOL according to the versioning scheme. The question is: how long? > Sounds like you'd want 2 years. Almost acceptable for me. I wish to save 2year lifetime period for FreeBSD. It take some time the release will be prepared for release. The (possible) new version of OpenSSL needs to be imported, all code that use them needs to be re-evaluated because of possible API changes, the resulting system needs to be tested. It take months. Check release process of any FreeBSD ... If you will declare 2year minimal lifetime for OpenSSL, it will be hard to reach even 1year lifetime for FreeBSD ... So I'm wishing for something about 3 years from OpenSSL ... Be sure I understand that any version supported require resources. I'm not picking numbers randomly just because it's simple to write a number here ... Dan