Precedence: list
MIME-Version: 1.0
In-Reply-To: <20180208224032.3942ce38@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> <cd4e6d83-c8d8-d654-955c-83cd96f5e6d8@adelielinux.org>
 <20180208224032.3942ce38@mechanicum.chadwicks.me.uk>
From: William Pitcock <nenolod@dereferenced.org>
Date: Thu, 8 Feb 2018 17:43:31 -0600
Message-ID: <CA+T2pCGRVWdbhnWqPP=0iD=Mc8TRR0mmsF062Rca6uqxhUBc=g@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 4:40 PM, Kevin Chadwick <m8il1ists@gmail.com> wrote:
>> > You clearly do not know about the extra protections and priviledge
>> > separation in LibreSSL!!!
>>
>> You must be talking about Pledge, which allows LibreSSL to declare
>> what system calls it will and will not be using.  Of course, Pledge
>> is only available in OpenBSD.
>
> No, Pledge is not priviledge seperation or even close to it, though it
> does benefit from it!
>
> Buffer overflows are far less dangerous with priviledge separation
> deployed and no the way you compile Alpine will not accomplish anything
> like proper priviledge seperation.

Alpine has been using privilege separation for years where possible
regardless of using LibreSSL or not.  Privilege separation would not
have prevented Heartbleed, as the unprivileged process would still
require a copy of the X509 objects in order to perform cryptographic
operations.
Also, buffer overflows are different than buffer over-reads.  An
over-read is when a read goes past the end of a buffer, an overflow is
when a write goes past the end of a buffer.  Heartbleed is an example
of an over-read, and the correct mitigation is to ensure that
allocation sizes are correct and non-contiguous.

> I guess you can see how with libtls then heartbleed would have had
> much less affect. OpenBSD have been pioneering in depth use of
> priviledge seperation with layers of security on top for years,

No, I am pretty sure I don't see how libtls would have protected
against Heartbleed (see above).

> _______________________________________________________________________
>
> As the OpenBSD 5.7 development effort comes to a close, so does the
> LibreSSL 2.1.x branch. The next release will begin the 2.2.x development
> branch.
>
> User-visible features:
>
>   * Improvements to libtls:
>     - a new API for loading CA chains directly from memory instead of a
>       file, allowing verification with privilege separation in a chroot
>       without direct access to CA certificate files.
> ________________________________________________________________________

This type of design is not provided by libtls itself, but libtls
provides the primitives for it.  It is also possible to accomplish
this design through the OpenSSL 1.0.1g API using a series of
SSL_CTX_add0_chain_cert() calls (which is essentially what libtls does
internally), or just loading the certificate chain into X509 objects
prior to calling fork(2).  It is important to note that the isolated
process still needs a copy of the X509 objects in memory in order to
perform cryptographic operations with the certificates (such as
setting up new TLS sessions), so the purpose of privilege separation
here would not be to "protect the keys."  They are needed in order to
do cryptographic operations.

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---