OpenSSL 1.1 support status : what next?

[Douglas E Engert]

OpenSC has taken a different approach to OpenSSL-1.1. Rather then writing
a shim for OpenSSL-1.1, the OpenSC code has been converted to
the OpenSSL-1.1 API and a sc-ossl-compat.h" file consisting of defines and
macros was written to support older versions of OpenSSL and Libressl.

https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc-ossl-compat.h

The nice part of this approach is when using OpenSSL-1.1 sc-ossl-compat.h
does not do anything. It sole purpose to provide calls to the older APIs
that are not going to change and eventually the sc-ossl-compat.h could be
removed.

Only the OpenSSL routines used by OpenSC have added to sc-ossl-compat.h
but others defines and macro could be added.There are a few utilities that
use still use a few #ifdef's during initialization.


On 6/23/2017 7:15 AM, The Doctor wrote:
> On Fri, Jun 23, 2017 at 01:53:24PM +0200, Emmanuel Deloget wrote:
>> Hello Ingo,
>>
>> On Fri, Jun 23, 2017 at 1:26 AM, Ingo Schwarze <schwarze at usta.de> wrote:
>>>
>>> Hi Emmanuel,
>>>
>>> Emmanuel Deloget wrote on Fri, Jun 23, 2017 at 12:26:47AM +0200:
>>>
>>>> * the openssl team has no real incentive to propose a shim ;
>>>
>>> If major application projects refuse to support their new release,
>>> thus putting pressure on operating system distributions to not
>>> completely switch to 1.1 either, that is not an incentive?
>>
>> Yes and no. The fact is that openssl is widely used by tons of projects.
>> Even if a major project quits (and frankly, these days openssh is built
>> around libressl, not openssl, so one car argue that openssh already leaved
>> the boat) there is little incentive for the openssl to not continue in the
>> same direction as other projects will follow anyway -- mostly because
>> openssl is openssl, not because openssl is great (*).
>>
>> Why would the openssl team do that ?
>>
>> * it's time consuming, and their time is better spent on enhancing the
>> security and features of the openssl libs
>> * such a project is doomed. It would make the various downstream project
>> move to the openssl 1.1 API, at which point the remaining distros will dump
>> older versions, meaning that the shim will have a life duration of one,
>> maybe two years.
>> * yet during these two years, it might become a stable (as introduces by
>> R.C. Martin : a stable software is one who as many clients and a limited
>> set of dependencies), meaning that every little change in it might have
>> tremendous effects on downstream projects.
>> * its a rewrite of code they already wrote in the openssl library.
>> * most of it is trivial
>> * your specific downstream needs are different than another downstream's
>> project need, so in order to satisfy everyone they'll have to build a
>> complete library. Which is basically a rewrite of what they already did.
>>
>> So, to rephrase the question, why would they spend time to propose a
>> difficult to maintain, not really needed, potentially large yet trivial,
>> doomed library?
>>
>>>> Did I miss something?
>>>
>>> Maybe you are striving for the wrong goal.  It is not a goal to
>>> clobber something together and encourage OpenSSL to repeat such
>>> recklessness in the future, and leave users out in the rain once
>>> again.
>>
>> I fully understand that the API change was/is difficult. Yet, it's a
>> proactive move (and not a bad one) to enhance downstream code and to limit
>> the impact of further changes. You don't have to micromanage a quadrillion
>> of structure members with confused semantics, meaning that there is less
>> chance to misuse them. Furthermore you no longer have access to what are
>> are really implementation details.
>>
>>> It is not a goal either to create a shim that is not
>>> officially audited and thoroughly tested by the original authors
>>> who know their original code best, to create a shim that creates
>>> additional dangers for security.  We are talking about security
>>> software here, so this is not the place at all to lightly cobble
>>> something together, in particular not in ways involving many lines
>>> of additional code.
>>
>>
>> And I fully get that as well.
>>
>> But since nobody will step in, one has to do the job. Luckily, many has
>> jumped in (and I was ready to do that as well). Their shim code is, as
>> expected, quite clear and it should be easy to spot anything suspicious or
>> wrong (I suspect some BN_free() should be replaced with BN_clear_free()
>> here and there, but for most part the BN_free() directly comes from the
>> openssl code).
>>
>> The fact is that most added functions are setters and getters, so until you
>> do things in the Widely Wrong Way, it should be ok :) I'm not talking about
>> rewrite RSA_public_encrypt() :)
>>
>>> If a few important projects keep up resistance and refuse support
>>> for 1.1 until OpenSSL rolls up their sleeves and fixes the mess
>>> they have created, maybe they will eventually realize that they
>>> started a job here, wandered off half-way, and failed to ever
>>> properly finish it.
>>
>> Or another, less important project that did the jump will replace it
>> because distros have limited patience w.r.t. softwares that do not want to
>> evolve their API. Once the 1.0.2 support is out, distros will want to have
>> 1.1 and softwares that do not want to move to that version will either be
>> patched or replaced. Other implementations already exist, including
>> dropbear, GNU lsh and probably others I don't know. Most of them are not as
>> good as openssh and some of them are downright horrible to use (I'm looking
>> at you, GNU lsh...) but the fact that some alternatives exists is what's
>> important here.
>>
>> You also must take into account that some people want to have openssl 1.1
>> for wahetever reason (for example, TLS1.3 support in 1.1.1). For them,
>> having to cope with multiple versions of the openssl library is not going
>> to work well. Distro maintainers will also be rightly pissed off if only
>> one important program does not want to take the jump.
>>
>>> So, such resistance has a chance to improve the situation for
>>> everybody.  And i can't think of many projects that are in as
>>> widespread use as OpenSSH, and hence can be more valuable with
>>> respect to such resistance.
>>
>> I'm not sure it's practical in the long term. Furthermore, one cannot
>> really expect that the openssl team will deprecate the 1.1 API and move
>> back to the Good Ol' Days of the 1.0.1 API. I'm not saying that resistance
>> is futile but I'm not sure it will have the desired effect.
>>
> 
> Unfortunately, Openssl will not be heading that way.
> 
> Opensl 1.0.X dies, that is it, Openssl 1.1.X upwards will be the standrard.
> 
> Other packages like Exim, INN, Curl and  Bind are adapating.
> 
> Even Claamav will adapat, just a 2 line fix.
> 
> In this case  resistance will go nowhere.
> 
>   >
>>> Just my personal 2 cents,
>>> yours,
>>>    Ingo
>>
>>
>> Best regards,
>>
>> -- Emmanuel Deloget
>>
>> (*) that does not mean openssl is not great.
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

-- 

  Douglas E. Engert  <DEEngert at gmail.com>