From owner-freebsd-security@FreeBSD.ORG Thu Jun 12 18:07:15 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 034CE6F6 for ; Thu, 12 Jun 2014 18:07:15 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BCA5627E6 for ; Thu, 12 Jun 2014 18:07:14 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 19D7335930A; Thu, 12 Jun 2014 20:07:11 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 07F7128497; Thu, 12 Jun 2014 20:07:11 +0200 (CEST) Date: Thu, 12 Jun 2014 20:07:10 +0200 From: Jilles Tjoelker To: Ben Laurie Subject: Re: OpenSSL end of life Message-ID: <20140612180710.GA98525@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-security@freebsd.org 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: Thu, 12 Jun 2014 18:07:15 -0000 On Wed, Jun 11, 2014 at 10:32:54AM +0100, Ben Laurie wrote: > We (the OpenSSL team) are considering a more aggressive EOL strategy. > In particular, we may EOL 0.9.8 right now, and 1.0.0 when 1.0.2 comes > out (currently in beta). > Going forward we would only maintain two versions, so when 1.0.3 comes > out, 1.0.1 would be EOL. > What do people think about this? I appreciate that the OpenSSL team is short on time, but such a change would be rather inconvenient for users. In particular, not only are new OpenSSL versions (like 0.9.8 and 1.0.0) ABI-incompatible, but it is unwise to even install more than one version of OpenSSL on a machine. Because different versions of libcrypto.so and libssl.so provide the same symbols, loading multiple versions into one process may cause a mixture of the versions to be used, which may lead to crashes and other nastiness. To be specific, various libraries and PAM modules in the FreeBSD base such as libarchive, libfetch, pam_krb5 and pam_ssh depend on OpenSSL libraries. Linking an executable to both one of these libraries and ports OpenSSL is a bad idea and may lead to strange combinations like using a 0.9.8 libcrypto with a 1.0.1 libssl and using a 1.0.1 libcrypto from code that wants 0.9.8 except for the symbols that were removed between 0.9.8 and 1.0.1. There are various possible solutions to at least allow installing multiple versions of OpenSSL safely, for easier migration, but none of them in FreeBSD or OpenSSL upstream. This situation is unfortunate, also because OpenSSL is otherwise so close (SSL_CTX object allows multiple independent clients within a process). Various Linux distributions are using a symbol versioning hack submitted in http://rt.openssl.org/Ticket/Display.html?id=1222&user=guest&pass=guest but ignored. FreeBSD supports these ELF features as well. A more portable alternative is renaming all symbols, for example using a huge header file containing lines like: #define SSL_new openssl101_SSL_new #define SSL_free openssl101_SSL_free Yet another alternative is an option for ld to store the DSO ld found a symbol in and have rtld look only in that DSO (and explicit interposers). For the longer term, a stable ABI across versions for the OpenSSL libraries seems an interesting idea (even if only for platforms like FreeBSD and glibc with GNU-style symbol versioning that allows multiple versions of the same symbol). -- Jilles Tjoelker