Precedence: list
MIME-Version: 1.0
In-Reply-To: <20180208192207.7e0da20a@mechanicum.chadwicks.me.uk>
References: <CA+T2pCGFeh30aEi43hAvJ3yoHBijABy_U62wfjhVmf3FmbNUUg@mail.gmail.com>
 <20180208180544.3ff19e66@mechanicum.chadwicks.me.uk> <CA+T2pCFi7iAqSxq500VYS=3a2GYTkF0akWhy6oVpL7B7O1N-Ew@mail.gmail.com>
 <20180208192207.7e0da20a@mechanicum.chadwicks.me.uk>
From: William Pitcock <nenolod@dereferenced.org>
Date: Thu, 8 Feb 2018 13:54:12 -0600
Message-ID: <CA+T2pCELcUjoVuVZO1kRQkZVf6G36i8WcObwaqj2G5g4TDLKiQ@mail.gmail.com>
Subject: Re: [alpine-devel] Proposed change: openssl 1.1 as default system
 openssl implementation
To: Kevin Chadwick <m8il1ists@gmail.com>
Cc: alpine-dev <alpine-devel@lists.alpinelinux.org>
Content-Type: text/plain; charset="UTF-8"

Hello,

On Thu, Feb 8, 2018 at 1:22 PM, Kevin Chadwick <m8il1ists@gmail.com> wrote:
> On Thu, 8 Feb 2018 12:53:06 -0600
>
>
>> Hello,
>>
>> On Thu, Feb 8, 2018 at 12:05 PM, Kevin Chadwick <m8il1ists@gmail.com>
>> 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
---