OpenSSL 1.1 support status : what next?

[Emmanuel Deloget]

Hello everybody,
​ ​

I saw that another discussion about OpenSSL 1.1 support started on this
list, and I'd like to know what is the current status about this.

>From what I understand, at least
​one
 patch set already exists:
​ ​
a github PR [1] from , Kurt Roeckx announced on the list in september 2016
[2]
​ and which also exist as a fedora patch [3]​ (I haven't checked the
details, and maybe the PR and the fedora patch are a bit different).

​The problems that were signaled during the september/november 2016
discussion and the recent one are:

* it breaks LibreSSL builds
* the changes are only relevant to openssh-portable
* it involves maintaining a shim which might be buggy
* openssl 1.0.2 is LTS and support is longer than for openssl 1.1.0
* a few major distributions (including some older RHEL versions) are stuck
with even older releases
​* changes in openssl 1.1 are not a sufficient motive to do the job anyway​
* this is quite a large change (the fedora patch is more than 3000 lines
long)

Forces that would drive the changes are:

* fedora already has it.
* latest debian unstable are to be based upon OpenSSL 1.1.
* ​eventually 1.0.2 will fade out so being ready to support openssl 1.1
(and later versions) is likely to pay out at some time
​* a late change is going to be even larger than the current fedora patch
(hello, technical debt). ​

​* ​new features in future openssl release

​I probably missed a few thing here and there.

Now, I recently completed a similar change for OpenVPN [4] - as the
currently proposed patch, it involves a shim, although this one is made of
static inlines in a header file. It allowed the OpenVPN team to add an
openssl 1.1 build target on travis and subsequent changes will be tested
against this build target (so new openssl 1.0.x artefact cannot be
introduced again in the code) as well as against already existing targets
(meaning that introducing the use of another openssl 1.1 function into the
code will force a change in the shim). So it basically takes care of
everything. Report has been made that it does not break the LibreSSL build.

For further ease of management, the shim itself is broken in multiple
parts. The configure script checks for the presence of each OpenSSL 1.1
needed function, and one #define is generated for each function. The code
does not really care if the function comes from 1.1.0 or 1.0.2.

​
I was in the process of doing something similar for openssh-portable when I
found out about Kurt's patch. His work is more advanced than mine, so I'm
wondering if I should continue (I can always rework his patch to adapt it
to the process I outline above ; furthermore I think there might be other
issues than the double free [5] in the code, but I have to double or triple
check my intuition here, as I kind of always get wrong when I state
something like this).

My opinion is:

* the openssl team has no real incentive to propose a shim ; moreover such
an "official" shim is not guaranteed to be used by downstream.
* an independant openssl shim project is likely to fail -- it stills
require a large amount of work for downstream projects as they still need
to adapt their code to the new openssl API.
* so downstream projects are kind of forced to implement their own shim
anyway
​. I fully understand that it's not an ideal solution.​

​
​I believe it's possible to build a shim with the following features:

* compatible with openssl 1.0 to 1.1 and current versions of libressl (e.g.
the one in OpenVPN has been tested with openssl 0.9.8 ; when I started
development RHEL 4 was not yet eol'ed)
* easy to change when an openssl version is deprecated
* small enough to avoid security bugs in the shim itself

The latest is especially important, and my intuition is that most of the
shim (if not all) is made of functions whose goal is to either get or set
openssl structure members. This code is quite straigtforward and should not
pose any threat.

Compatibility with libressl is granted as long as the shim implement
missing (openssl 1.0.2+) functions using the openssl 1.0.1 API. This should
be guaranteed until the eol of openssl 1.0.2. A problem may arise if we
need to implement openssl 1.2+ API using the openssl 1.1 API (yet we still
have some time before we'll face this situation).

Ease of change is always relative, but the goal is to limit the number of
changes when one must add or remove a function from the shim.

​Did I miss something? ​Is the community interested in having support for
openssl 1.1? What should an ideal openssl 1.1 support look like? Do you
have any question? Comment? How many question mark can I add in the
paragraph?

​Best regards,

-- Emmanuel Deloget​

[1] https://github.com/openssh/openssh-portable/pull/48
[2]
http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-September/035378.html
​[3]
http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/tree/openssh-7.3p1-openssl-1.1.0.patch
​
[4] https://github.com/OpenVPN/openvpn
[5]
http://lists.mindrot.org/pipermail/openssh-unix-dev/2017-June/036083.html