X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail-qt0-f182.google.com (mail-qt0-f182.google.com [209.85.216.182]) by lists.alpinelinux.org (Postfix) with ESMTP id 3BC785C4E50 for ; Thu, 8 Feb 2018 19:54:13 +0000 (GMT) Received: by mail-qt0-f182.google.com with SMTP id q18so990143qtl.3 for ; Thu, 08 Feb 2018 11:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dereferenced-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KiOpz7vhFQ/lcufThhHsMAe/E3roeIkPJ/0i/EzJcd0=; b=Yu1E9dhtVcpZQLOU0M1i50K7vLTxscYUjmqbCjvlNkpLuvxC1tGSwUb0C6WvnsxDag yLitxROxK0fxroaZRAW55dAgAu08UOfjLpv5gW0WHdoVTrK9GTSHisG7rStVB/oJRgtj pfQcbDv4bHC01vkbdG7HRYZPQIIS/9zcclZCvC/h6Z8U3nfL6BWflCChRN2wXami8jcI gVvBzojTA6UxX1hOZXsapYPtMHR4PxtOmnakJPQq/y6K+whjoqvHlUXPz5Ux5/qkRKqh zDT4f/yhgDsADNHhM6Wxg6tYKzhracryIhpqMrHfYmN5M2MHhO90PUTz37SCN8ExtsCR ACsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KiOpz7vhFQ/lcufThhHsMAe/E3roeIkPJ/0i/EzJcd0=; b=KKumDmaNLCQ2wRm4v4GYwle8pWq5H2bcFKaaUCDbt4bnvH3K3u3fu910mlv/HBQxzM VsqbVOjSM9lPX+dAomIfkCkHpwwzL4kUuWXGKuBq9erkjJ7sipVc6Ihu7qpj0VTK6YRx gmFfN4NJcZ34h7YsCXUFQopYLMvGLU1GMDzxPPUqvPQqzQ/xGNOpD/25l6GMBSjy3/L3 fnUJKC3+9+UOtaZi73SnQgfzVCeSgAQQfEfLsnB+Dk6r47MILi+vTOTjfst5S9PcJcVh EvKvEuimguwtqCaOT7i/4eBnkLeBaiNhv5FQfRLe3PgDfDDVnvgmV/buMR4oJnkejyxf h6bw== X-Gm-Message-State: APf1xPAO7VS7zWHWNMD2txqK6wwhnspNhda+zQ3bW7sSWRAiKCDgAQgR IV//eOvWMENgeUmxBfPgyvVj0OXrj+78djmmqYckCA== X-Google-Smtp-Source: AH8x227GfbsyIpJfglKHpR8nduIBMQ9qMnNw/ipiqeKgQ52XqK4va9gIlKfxg1z7BrOVYGHCpuhmtlnHDfL0dtlefR0= X-Received: by 10.200.26.173 with SMTP id x42mr606076qtj.288.1518119652500; Thu, 08 Feb 2018 11:54:12 -0800 (PST) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Received: by 10.200.39.100 with HTTP; Thu, 8 Feb 2018 11:54:12 -0800 (PST) In-Reply-To: <20180208192207.7e0da20a@mechanicum.chadwicks.me.uk> References: <20180208180544.3ff19e66@mechanicum.chadwicks.me.uk> <20180208192207.7e0da20a@mechanicum.chadwicks.me.uk> From: William Pitcock Date: Thu, 8 Feb 2018 13:54:12 -0600 Message-ID: Subject: Re: [alpine-devel] Proposed change: openssl 1.1 as default system openssl implementation To: Kevin Chadwick Cc: alpine-dev Content-Type: text/plain; charset="UTF-8" Hello, On Thu, Feb 8, 2018 at 1:22 PM, Kevin Chadwick wrote: > On Thu, 8 Feb 2018 12:53:06 -0600 > > >> Hello, >> >> On Thu, Feb 8, 2018 at 12:05 PM, Kevin Chadwick >> wrote: >> > On Thu, 8 Feb 2018 11:23:26 -0600 >> > >> > >> >> Meanwhile, the libressl guys have been removing >> >> functionality we depend on, such as support for hardware >> >> accelerators (ENGINE apis), switching from 64-bit TAIN date >> >> calculations to time_t (because time_t is good enough on OpenBSD) >> >> and dropping openssl 1.0.1 APIs they see as unsuitable. >> > >> > This is a strange take on the situation to say the least. >> >> I would argue that 32-bit systems not being able to validate >> certificates from CAs who have expiry dates past year 2038 is a major >> security problem. This is caused by the elimination of the TAI64N >> date calculation code. > > That is not the part that I was referring to, however as I > understand it this isn't an issue on OpenBSD or any constrained > embedded system that I develop?? It is not an issue on OpenBSD, they have a 64-bit time_t across all architectures. Unfortunately, the Linux kernel does not yet offer a syscall ABI that allows a 64-bit time_t on 32-bit architectures. There is some added expense in implementing such a syscall ABI due to the way the Linux syscall ABI works in general, but they are working to fix the syscalls. Accordingly, this is an issue on Alpine 32-bit systems, where today, LibreSSL will fail to validate certificate chains where the root CA has already been updated to a expiry greater than year 2038. >> > Apis were dropped for good reasons and they have committed to >> > implementing new API components that seem sensible and are most >> > desired. However the primary goal is security not functionality and >> > if anything you could argue that OpenSSL is still way too complex >> > to be fit for purpose. >> > >> > Multiple CVEs have been avoided by LibreSSL already. >> >> Those CVEs were not avoided by removal of the functionality I listed >> above. In fact, the removal of the functionality I listed above has >> introduced security regressions. >> > > That wasn't the point and I doubt you actually know that, but nvm. I understand your point: less code means less bugs. While this is typically true, the real fix is to kick the OpenSSL habit altogether. This means encouraging upstreams to use neither LibreSSL nor OpenSSL. If OpenSSL is heroin, LibreSSL is methadone. >> >> libressl promised to retain compatibility with 1.0.1g APIs, but has >> >> failed to do so. >> > >> > I am not clear on the versions but I do know that they promised to >> > be a replacement at the time and whilst I am not really involved I >> > have seen comments that OpenSSL seem to be purposefully causing >> > issues. >> >> This is not the case; LibreSSL have removed APIs that were part of the >> OpenSSL 1.0.1g set. It is possible today, to have a program which >> successfully compiles under OpenSSL 1.0.1g (e.g. the release at the >> time of the LibreSSL fork) and fails to compile under LibreSSL. >> Accordingly, they broke their promise. >> > > Christian Heimes - > > The situation is, LibreSSL hasn't been compatible with any supported > OpenSSL version since 2017-01-01. The lack of compatibility with the > industry standard OpenSSL either means: drop LibreSSL or don't improve > security of Python's ssl module. 1 reply 0 retweets 1 like OpenSSL 1.0.1g is still supported by Python. This kind of demonstrates my point, now doesn't it? > > Mark Espie - > > you've got to realize that openssl deliberately broke compatibility > with previous versions precisely to try to stop libressl. we're talking > crypto, more fluffy interfaces are not necessarily better. Especially > when they allow people to create insecure crypto. It is possible to build OpenSSL 1.0.1g applications against OpenSSL 1.1 without major modifications. But as a developer, it is the responsibility of the developer to follow the evolution of the APIs you are using. As for breaking compatibility with previous versions to stop libressl: the problem is actually that LibreSSL made downstream changes and OpenSSL made equivalent changes, and the APIs are different. This may or may not be intentional, but it does not matter to me because my points are focused on the OpenSSL 1.0.1g API compatibility which is the same for both libraries. >> >> As such, there is an increasing workload to keep >> >> packages compatible with libressl as it evolves. Therefore, it is >> >> obviously not truly a suitable provider for the openssl package, >> >> and we should switch back to proper openssl as the default. We >> >> will >> > >> > Do you have a list of packages at all? >> > >> > proper!?!? I guess LibreSSL has less resources and hope that is what >> > you meant. >> >> By proper, I mean an implementation that is conformant with the >> OpenSSL 1.0.1g API, which is what was promised by LibreSSL. >> > > Is OpenSSL conformant, see above? Yes. >> > I believe the key protection improvements were/are better in >> > LibreSSL and so the fix for heartbleed was properly done! >> >> The protection improvements are the same: the custom memory management >> code has been removed from both. >> > > You clearly do not know about the extra protections and priviledge > separation in LibreSSL!!! Privilege separation does not protect against buffer overruns. Also, most likely, the "extra protections" you refer to are already present in Alpine's OpenSSL package as an effect of how we build OpenSSL. >> > I understand your workload point and that Alpine is far from in >> > control over this but I don't like how this mail has been written >> > and wonder what environment caused that? Also, there are other >> > libraries like mbedtls and boring ssl, aren't these packages >> > breaking compatibility with them and reducing their scope? (Not an >> > alpine issue of course) >> >> mbedtls has never implemented the OpenSSL API. BoringSSL is not >> appropriate as a system openssl implementation, it is mostly to >> support Chromium and other Google products. >> > > But packages like python have been demonstrated to run on the > constrained systems that they are designed for. OpenSSL is way too big. > I agree this is a Linux rather than Alpine issue, except for your desire > for more archs. OpenSSL and LibreSSL have less than 1MB installed size difference. Nobody has ever said "lets save resources by installing an OpenSSL fork instead of OpenSSL." Resource constrained systems almost always use a library designed for embedded use from the beginning, such as mbedTLS or BearSSL. We should absolutely do the same in apk-tools, so there is no OpenSSL/LibreSSL implementation on the system to begin with. >> > So maybe the packages like Python have an agenda or should slow >> > down? Python could also remove RWX memory requirements by default >> > as a higher priority? >> >> Any interpreter which has the ability to JIT (such as Python 3.6 with >> an appropriate JIT module loaded) requires RWX. PaX will never allow >> a page which has been marked PROT_WRITE to ever become PROT_EXEC. It >> is what it is, and it's also unrelated to the LibreSSL vs OpenSSL 1.1 >> discussion. >> > > The point was that maybe Python should sort that out before removing > code here. And my point is that there is nothing to sort out. Also, to be clear, Python was never an element of my rationale for switching the default. >> A stand for what? LibreSSL has removed support for things we want, >> such as cryptographic accelerators and TAIN-based date calculations. >> Neither of those functionality were removed for security reasons, but >> instead because the OpenBSD developers did not want to deal with >> maintaining them. I can understand their decision in doing so, but >> that doesn't mean that the cost-benefit analysis works out favorably >> for us anymore. > > I disagree as explained at the time of their removal. You don't want > hairy/dangerous code in a security library. TAI64N is less hairy and less dangerous than POSIX time_t date calculations because they are provably accurate. I will admit that cryptographic accelerator support can be tricky to get right, however. > I guess you think PAM is great too? I believe PAM should be sandboxed with privilege separation and thankfully in Adelie we have been scheming a way to do this, but this is unrelated to LibreSSL vs OpenSSL. I will write to the list about upstreaming PAM sandboxing once we have proven it in Adelie Linux 2. William --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---