Hi, more or less a year ago Kurt Roeckx provided an initial port towards the OpenSSL 1.1 API [0]. The patch has been left untouched [1] and it has been complained about a missing compat layer of the new vs the old API within the OpenSSL library [2]. This is how I reconstructed the situation as of today and I am not aware of any progress in regard to the newer library within the OpenSSH project. Did I miss any significant development? In the `meantime', OpenSSL provides a kind of compat layer [3] which (they suggested) should be included in the downstream projects [4]. Is this enough / acceptable? What would the project like to see? I know that OpenBSD itself is more focused on the LibreSSL library but I would like to avoid that every one carries (and maintains) a big patch around. [0] https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-September/035378.html [1] I know that Fedora ships it. [2] https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035456.html [3] https://wiki.openssl.org/images/e/ed/Openssl-compat.tar.gz [4] https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes#Compatibility_Layer Sebastian
Hi Sebastian, Sebastian Andrzej Siewior wrote on Fri, Oct 13, 2017 at 11:58:12PM +0200:> more or less a year ago Kurt Roeckx provided an initial port towards the > OpenSSL 1.1 API [0]. The patch has been left untouched [1] and it has > been complained about a missing compat layer of the new vs the old API > within the OpenSSL library [2]. > This is how I reconstructed the situation as of today and I am not > aware of any progress in regard to the newer library within the OpenSSH > project. Did I miss any significant development?No, i'm not aware that OpenSSL provided any further help for downstream projects who are forced to provide continued support for the 1.0 API. Note that even switching over LibreSSL to the OpenSSL-1.1 API - which would be a huge effort, and it's unclear if and when it might happen - would not solve the main problem because OpenSSH must remain able to build on operating systems that provide OpenSSL-1.0 only.> In the `meantime', OpenSSL provides a kind of compat layer [3] which > (they suggested) should be included in the downstream projects [4]. > > Is this enough / acceptable? What would the project like to see? I know > that OpenBSD itself is more focused on the LibreSSL library but I would > like to avoid that every one carries (and maintains) a big patch around. > > [0] https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-September/035378.html > [1] I know that Fedora ships it. > [2] https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035456.html > [3] https://wiki.openssl.org/images/e/ed/Openssl-compat.tar.gz > [4] https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes#Compatibility_LayerThat question is slowly turning into a frequently answered one: https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-July/036115.html Nobody commented on that cautious assessment, so i think it is safe to reword the answer more explicitly, even though that may seem slightly more aggressive: The so-called "compatibility layer" on that wiki page [4] you quote appears to be incomplete, untested, unmaintained, hence untrustworthy and unusable in a security context like OpenSSH. Consequently, no support for OpenSSL-1.1 is in sight. If you want to run on an operating system that burnt all bridges and only supports OpenSSL-1.1 but no longer OpenSSL-1.0, then the only responsible thing you can do is to build OpenSSH against LibreSSL rather than against OpenSSL on that platform. It should work quite well because LibreSSL supports a wide range of modern platforms by now: https://www.libressl.org/releases.html Note that on operating systems with a good package manager, it *is* possible to install LibreSSL and OpenSSL in parallel. For example, OpenBSD contains LibreSSL by default, yet you can easily install a port of OpenSSL in parallel if you want to, simply by issuing the command # pkg_add openssl without need for any further manual configuration. The reverse can be implemented on systems that use OpenSSL by default. Yours, Ingo
On Fri, 13 Oct 2017, Sebastian Andrzej Siewior wrote:> Hi, > > more or less a year ago Kurt Roeckx provided an initial port towards the > OpenSSL 1.1 API [0]. The patch has been left untouched [1] and it has > been complained about a missing compat layer of the new vs the old API > within the OpenSSL library [2]. > This is how I reconstructed the situation as of today and I am not > aware of any progress in regard to the newer library within the OpenSSH > project. Did I miss any significant development? > > In the `meantime', OpenSSL provides a kind of compat layer [3] which > (they suggested) should be included in the downstream projects [4].The compatibility layer is unversioned, incomplete, barely documented and seems to be unmaintained. Because it isn't a library, they require it to be added to downstream projects directly. This isn't even close to a solution. In the absence of any progress, I'm considering adding some build sugar to simplify the process of building (and possibly fetching) LibreSSL as port of the OpenSSH build process. AFAIK Apple's OpenSSH distribution is already linked against LibreSSL (and of course, OpenBSD does too), so IMO it's had enough road-testing for general use. -d
Damien Miller wrote:> I'm considering adding some build sugar to simplify the process of > building (and possibly fetching) LibreSSL as port of the OpenSSH > build process.Please don't add any fetching, even opt-in, at the very least. It's often a mistake, and a decision that is difficult to revert once it becomes taken for granted. Thanks //Peter
Hello Sebastian, Sebastian Andrzej Siewior wrote:> Hi, > > more or less a year ago Kurt Roeckx provided an initial port towards the > OpenSSL 1.1 API [0]. [SNIP]You could use PKIX-SSH - http://roumenpetrov.info/secsh/ . Recent version 11.0, offers "forward" compatibility with OpenSSL, i.e. supports "STORE"-API that will be in 1.1.1. PKIX-SSH offers compatibility even with alpha versions of OpenSSL 1.1 API - for instance PKIX-SSH 8.7 works with 1.1.0-pre1 and 1.1.0-pre2 ( http://roumenpetrov.info.example.net/secsh/index-20160310.html#news20160116 ) . Ancient versions of OpenSSL cryptographic library are supported as well. PKIX-SSH works fine with specific library builds like FIPS enabled or Kerberos enabled. Also you could build PKIX-SSH with openssl compatible libraries but be careful with X.509 algorithms - as some OpenSSL CVE defects may be are not fixed yet into compatible libraries. You could find prebuild binaries for Android devices packaged into SecureBox .> SebastianRegards, Roumen Petrov -- Secure shell with X.509 certificate support http://roumenpetrov.info/secsh/
On 2017-10-14 11:40:30 [+1100], Damien Miller wrote:> The compatibility layer is unversioned, incomplete, barely documented > and seems to be unmaintained. Because it isn't a library, they require > it to be added to downstream projects directly. This isn't even close > to a solution.It can't be a library like lib-ossl-compat.so or so. All data struct became opaque and all that "compat" layer is doing is providing the accessor functions which have to be used in openssl 1.1 and were not around in earler openssl versions. So you can use the accessor function and don't have to care about the crypto library. Providing a library like lib-ossl-compat.so would required to be compiled against the same libssl.so _and_ would require a so bump each time the now opaque struct has been modified (since it would export the hidden opaque struct). This would defeat the purpose of making them opaque in the first place. What they did is simply collect the accessor which were needed in order to be able to compile against both versions. Are you saying, that you do not accept a wrapper like static inline int EVP_CIPHER_CTX_key_length(const EVP_CIPHER_CTX *ctx) { return ctx->key_len; } and prefer accessing ctx->key_len directly instead? Except for the different function, the resulting code should be identical when compiled against libressl. It also shouldn't be problemantic from the security / maintainance point of view since the wrapper does exactly what you would do while using libressl anyway. The worst thing that could happen is that you perform some kind of access which is not yet covered by a wrapper function. But this isn't something you should care about, the openssl 1.1 users would notice it and send I patch. I guess you might be annoyed but those patches. Other than that, it should be fine.> In the absence of any progress, I'm considering adding some build sugar > to simplify the process of building (and possibly fetching) LibreSSL as > port of the OpenSSH build process. AFAIK Apple's OpenSSH distribution is > already linked against LibreSSL (and of course, OpenBSD does too), so > IMO it's had enough road-testing for general use.Please don't. This reads like you are thinking about embedding a library into the openssh project. Distros don't like this. It has security implications.> -dSebastian
On 2017-10-14 01:24:11 [+0200], Ingo Schwarze wrote:> Hi Sebastian,Hi Ingo,> No, i'm not aware that OpenSSL provided any further help for > downstream projects who are forced to provide continued support > for the 1.0 API.There is just the Wiki things I pointed out.> Note that even switching over LibreSSL to the OpenSSL-1.1 API - which > would be a huge effort, and it's unclear if and when it might happen - > would not solve the main problem because OpenSSH must remain able > to build on operating systems that provide OpenSSL-1.0 only.Yes. The compat layer should be fine. The version check should be #if (OPENSSL_VERSION_NUMBER < 0x10100000L) || defined(LIBRESSL_VERSION_NUMBER) to deal with libressl but other than that it should work - it worked for other projects.> That question is slowly turning into a frequently answered one: > > https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-July/036115.html > > Nobody commented on that cautious assessment, so i think it is safe to > reword the answer more explicitly, even though that may seem slightly > more aggressive: > > The so-called "compatibility layer" on that wiki page [4] you quote > appears to be incomplete, untested, unmaintained, hence untrustworthy > and unusable in a security context like OpenSSH.It might be incomplete. I can't comment on maintained. All it really does is to provide access for the opaque structs so I don't understand the "untrustworthy" & "unusable in a security context" because the libressl version would look exactly the same.> Consequently, no support for OpenSSL-1.1 is in sight.And this will remain as-is until in 2020? This is when OpenSSL 1.0.2 is no longer maintained. So by then it has either work with 1.1 or people must use libressl instead.> If you want to run on an operating system that burnt all bridges > and only supports OpenSSL-1.1 but no longer OpenSSL-1.0, then the > only responsible thing you can do is to build OpenSSH against > LibreSSL rather than against OpenSSL on that platform. It should > work quite well because LibreSSL supports a wide range of modern > platforms by now:Responsible you name it. Okay. I would like to find a sollution without the need to package libressl. One way would be to keep 1.0.2 around until 2020 but?> Yours, > IngoSebastian
On Sat, Oct 14, 2017 at 11:40:30AM +1100, Damien Miller wrote:> On Fri, 13 Oct 2017, Sebastian Andrzej Siewior wrote: > > more or less a year ago Kurt Roeckx provided an initial port towards the > > OpenSSL 1.1 API [0]. The patch has been left untouched [1] and it has > > been complained about a missing compat layer of the new vs the old API > > within the OpenSSL library [2]. > > This is how I reconstructed the situation as of today and I am not > > aware of any progress in regard to the newer library within the OpenSSH > > project. Did I miss any significant development? > > > > In the `meantime', OpenSSL provides a kind of compat layer [3] which > > (they suggested) should be included in the downstream projects [4]. > > The compatibility layer is unversioned, incomplete, barely documented > and seems to be unmaintained. Because it isn't a library, they require > it to be added to downstream projects directly. This isn't even close > to a solution.Fair enough; but at the risk of telling you something you already know, the situation where distributions that want to get off old versions of OpenSSL have to choose between packaging LibreSSL (and thus, in practice, ending up maintaining multiple SSL library versions, which is exactly what our security teams tend to want to keep to a minimum) or passing around samizdat versions of an enormous patch is not exactly ideal either. It's kind of an unedifying stalemate. https://mta.openssl.org/pipermail/openssl-users/2017-April/005540.html suggests that the OpenSSL folks want an external contributor to maintain such a layer. I've been trawling back through OpenSSL mailing lists and not found much else in the way of discussion about this, although of course I could have missed something. Has there been any discussion between the two sets of developers about all this, or is it all sort of arm's length? Is it actually a requirement that an API compatibility layer be maintained by the OpenSSL team, or could a hypothetical group of external developers interested in breaking this stalemate fork openssl-compat.tar.gz, stick it in a git repository somewhere, and start making versioned releases and trying to address the other problems you describe? Of course that's only really a worthwhile exercise if OpenSSH would be willing to use it, and it would be good to limit the scope of the problem to "things needed by the handful of projects that really need this" rather than "the entire OpenSSL 1.0 API". (I am not at all sure I want to be one of such a hypothetical group of developers, and I definitely don't want to be in it on my own, but it might be better than the alternatives. At the moment it seems clear that neither the OpenSSL nor OpenSSH developers want the task.)> In the absence of any progress, I'm considering adding some build sugar > to simplify the process of building (and possibly fetching) LibreSSL as > port of the OpenSSH build process. AFAIK Apple's OpenSSH distribution is > already linked against LibreSSL (and of course, OpenBSD does too), so > IMO it's had enough road-testing for general use.This would be a pretty bad option for me as a distributor - it'd mean I'd have to keep track of LibreSSL security updates. -- Colin Watson [cjwatson at debian.org]
On 13/10/2017 23:58, Sebastian Andrzej Siewior wrote:> Hi, > > more or less a year ago Kurt Roeckx provided an initial port towards the > OpenSSL 1.1 API [0]. The patch has been left untouched [1] and it has > been complained about a missing compat layer of the new vs the old API > within the OpenSSL library [2]. > This is how I reconstructed the situation as of today and I am not > aware of any progress in regard to the newer library within the OpenSSH > project. Did I miss any significant development? > > In the `meantime', OpenSSL provides a kind of compat layer [3] which > (they suggested) should be included in the downstream projects [4]. > > Is this enough / acceptable? What would the project like to see? I know > that OpenBSD itself is more focused on the LibreSSL library but I would > like to avoid that every one carries (and maintains) a big patch around. > > [0] https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-September/035378.html > [1] I know that Fedora ships it. > [2] https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-November/035456.html > [3] https://wiki.openssl.org/images/e/ed/Openssl-compat.tar.gz > [4] https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes#Compatibility_LayerFor what it is worth - FYI only - I expect on AIX the "1.0.0" ABI will stay around for awhile - e.g., the fileset called openssl-1.0.2 still contains openssl-0.9.8 to support 'historical' applications. root at x064:[/data/prj/aixtools/curl-7.56.0/lib]ar tv /usr/lib/libssl.a rwxr-xr-x 537912/767508 726474 Oct 18 11:38 2016 libssl.so rwxr-xr-x 537912/767508 726474 Oct 18 11:38 2016 libssl.so.1.0.0 rwxr-xr-x 537912/767508 510610 Oct 18 11:39 2016 libssl.so.0.9.8 The "default" - when it comes to new applications is the first archive in the archive - notice the 'named' version is still libfoo.so.1.0.0, I suppose - if I was running into compatibility conflicts with openssl - I would look at the experimental configure flag (-nossl iirc). IBM is on their own track - still supplying OpenSSH based on either OpenSSH-6.0p1 or OpenSSH-7.1p1. From the bits I have read - you will be safe to do whatever you want on openbsd - and the UNIX/Linix distros will follow way behind (Centos-1116 is around: OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips 11 Feb 2013 - via the DVD. And, yes - I need to update it. Will get there eventually - part of the project I am working on atm. My guess is that only OpenBSD and admins that do their own packaging will be current. Thos who depend on the official updates will be behind. M> > Sebastian > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev