Status of OpenSSL 1.1 support
Emmanuel Deloget
logout at free.fr
Tue Oct 17 03:56:44 AEDT 2017
Hello everyone,
On Mon, Oct 16, 2017 at 5:18 PM, Ingo Schwarze <schwarze at usta.de> wrote:
> Hi Colin,
>
> Colin Watson wrote on Mon, Oct 16, 2017 at 10:26:03AM +0100:
>>
<snip>
>> I realise that this is not the OpenSSH team's
>> problem as such, and that as a LibreSSL developer you may well not be
>> super-sympathetic to this argument; but nevertheless, I don't think this
>> is a viable option right now for us as a distributor.
>
> I completely understand that you are in a difficult situation and
> that you like none of the options you have:
>
> (1) package LibreSSL
> (2) bundle LibreSSL
> (3) keep the existing OpenSSL-1.0 package (still supported upstream)
>
> Until somebody sufficiently qualified maintains a compat library,
> *and* LibreSSL gains 1.1-compatible interfaces *and* OpenSSH switches
> over (three large items lacking volunteers, which consequently seem
> very unlikely to be completed by the end of the year), these three
> are the only options i can see.
Let's restate these in numbered bullet points:
(a) somebody sufficiently qualified maintains a compat library
(b) LibreSSL gains 1.1-compatible interfaces
(c) OpenSSH switches over
I'm not sure point (b) is necessary. The goal of the shim is to
emulate the OpenSSL 1.1 interface by encapsulating OpenSSL 1.0 /
LibreSSL code, so no change is needed in the upstream library (that
would make the change really impossible IMHO). So the problem goes
down to 2 point: (a) and (c).
>From my experience, (a) is not that problematic. The goal is not to
add any cryptographic code in the shim. Doing that would be both quite
dangerous and not very productive since downstream users are not using
theses (new) features anyway. The goal for now is to use the OpenSSL
1.1 API, not OpenSSL 1.1 itself. Good news: the shim code is quite
neutral (w.r.t. security) and often very simple.
If you really give a look to the Fedora patch [1] (and I encourage
everyone who's serious about porting OpenSSL to OpensSSL 1.1 to do so,
without judging the quelity of the patch itself), you'll see that the
shim itself is less than 550 lines long. Most of the patch deals with
changing the OpenSSH code to match the new API (some of the functions
used in this patch are older and are already present in OpenSSL 1.0
and LibreSSL). At a first glance, this shim code seems to be mostly
extracted from the OpenSSL 1.1 code and is trivial in many cases.
There are parts that require some attention (again, w.r.t. security)
but even those are quite simple (most of these if not all are related
to memory management). In any case it does not require the mastery of
the crypto code in OpenSSL.
Thus I would say that the real problematic point is point (c): is the
OpenSSL team comfortable with changing the OpenSSH code to support
this API?
Changing openssh-portable but not openssh means the two versions are
likely to diverge at some point, so the wise among us would call for a
global change (i.e. make openssh compatible with the OpenSSL 1.1 API
and port the changes to openssh-portable). As I understood it, this
would be problematic because openssh does not target OpenSSL at all,
so that would introduce a number of changes that are not needed into
the code base.
The change is not as urgent as it may seem: OpenSSL 1.0.2 is to be
supported for another 14 monthes so unless distributions want to phase
it out earlier, there is still time to do it (I do understand that
some distributions are phasing out OpenSSL 1.0).
> Yours,
> Ingo
BR,
-- Emmanuel Deloget
[1] http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/tree/openssh-7.3p1-openssl-1.1.0.patch
More information about the openssh-unix-dev
mailing list