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
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?> 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. 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. 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. 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. Just my personal 2 cents, yours, Ingo
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.> > Just my personal 2 cents, > yours, > IngoBest regards, -- Emmanuel Deloget (*) that does not mean openssl is not great.