Bug#918727: [Pkg-openssl-devel] Bug#918727: Bug#918727: openssl.cnf incompatible with libssl1.0.2, libssl1.0.0

[Sebastian Andrzej Siewior]

On 2020-04-21 21:39:43 [+0200], Kurt Roeckx wrote:
> On Tue, Apr 21, 2020 at 09:18:05PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2020-04-15 13:38:23 [+0200], Kurt Roeckx wrote:
> > > On Wed, Apr 15, 2020 at 12:19:24PM +0100, Simon McVittie wrote:
> > > > 
> > > > I think setting defaults in the shared library itself would be more
> > > > robust, and if a configuration file to override that is necessary,
> > > 
> > > This is also the route that Ubuntu took, because it's possible to
> > > install the library without the openssl package. I think we should
> > > do this too.
> > > 
> > > It causes various issues with the test suite because SHA1 is used
> > > for various tests. But I think that has been fixed in master, or has a
> > > pull request.
> > > 
> > > I would like to drop SHA1 support in testing/unstable anyway, so I
> > > think we should merge those patches once they've all been merged.
> > 
> > Ehm. I read this a few times but I have no idea what we are going to do.
> > Could you please enlighten me?
> 
> It's about building with -DOPENSSL_TLS_SECURITY_LEVEL=2, and
> something like the patch I've used before to set the default TLS
> version, instead of having both in openssl.cfg. Setting it in the
> config file should override the build time defaults.

So if this replaces the entry openssl.cnf file then it would get rid of
that incompatible part. However if someone downgrades it for some reason
(by editing the file) then we are back to the incompatibility part where
things break if the syntax changes.

> Building with that set will cause testsuite errors. Some of those
> are because SHA1 is being used.

Yes. I suggested once to ship that .cnf file as part of libssl but you
didn't like the  idea, dunno why. But I know that you said that openssl
is almost always installed due to ca-cert and so on so…

> In the master branch, things are changing so that SHA1 isn't
> allowed at security level 1 anymore. For the next release, if
> we're not shipping 3.0, I would like to at least change that.

No SHA1 at level1? Lovely. You remember this one CDN that signed the
key-exchange with SHA1 despite the fact that the client did not offer
it? I just checked it, it is still doing it. And ssllabs.com does not
report this "bug" as such. I hope the web browsers have SHA1 also on
their agande because otherwise…

> Kurt

Sebastian

Bug#918727: [Pkg-openssl-devel] Bug#918727: Bug#918727: openssl.cnf incompatible with libssl1.0.2, libssl1.0.0

[Kurt Roeckx]

On Tue, Apr 21, 2020 at 09:18:05PM +0200, Sebastian Andrzej Siewior wrote:
> On 2020-04-15 13:38:23 [+0200], Kurt Roeckx wrote:
> > On Wed, Apr 15, 2020 at 12:19:24PM +0100, Simon McVittie wrote:
> > > 
> > > I think setting defaults in the shared library itself would be more
> > > robust, and if a configuration file to override that is necessary,
> > 
> > This is also the route that Ubuntu took, because it's possible to
> > install the library without the openssl package. I think we should
> > do this too.
> > 
> > It causes various issues with the test suite because SHA1 is used
> > for various tests. But I think that has been fixed in master, or has a
> > pull request.
> > 
> > I would like to drop SHA1 support in testing/unstable anyway, so I
> > think we should merge those patches once they've all been merged.
> 
> Ehm. I read this a few times but I have no idea what we are going to do.
> Could you please enlighten me?

It's about building with -DOPENSSL_TLS_SECURITY_LEVEL=2, and
something like the patch I've used before to set the default TLS
version, instead of having both in openssl.cfg. Setting it in the
config file should override the build time defaults.

Building with that set will cause testsuite errors. Some of those
are because SHA1 is being used.

In the master branch, things are changing so that SHA1 isn't
allowed at security level 1 anymore. For the next release, if
we're not shipping 3.0, I would like to at least change that.


Kurt

Bug#918727: [Pkg-openssl-devel] Bug#918727: Bug#918727: openssl.cnf incompatible with libssl1.0.2, libssl1.0.0

[Sebastian Andrzej Siewior]

On 2020-04-15 13:38:23 [+0200], Kurt Roeckx wrote:
> On Wed, Apr 15, 2020 at 12:19:24PM +0100, Simon McVittie wrote:
> > 
> > I think setting defaults in the shared library itself would be more
> > robust, and if a configuration file to override that is necessary,
> 
> This is also the route that Ubuntu took, because it's possible to
> install the library without the openssl package. I think we should
> do this too.
> 
> It causes various issues with the test suite because SHA1 is used
> for various tests. But I think that has been fixed in master, or has a
> pull request.
> 
> I would like to drop SHA1 support in testing/unstable anyway, so I
> think we should merge those patches once they've all been merged.

Ehm. I read this a few times but I have no idea what we are going to do.
Could you please enlighten me?

> 
> Kurt

Sebastian

Bug#918727: [Pkg-openssl-devel] Bug#918727: Bug#918727: openssl.cnf incompatible with libssl1.0.2, libssl1.0.0

[Kurt Roeckx]

On Wed, Apr 15, 2020 at 12:19:24PM +0100, Simon McVittie wrote:
> 
> I think setting defaults in the shared library itself would be more
> robust, and if a configuration file to override that is necessary,

This is also the route that Ubuntu took, because it's possible to
install the library without the openssl package. I think we should
do this too.

It causes various issues with the test suite because SHA1 is used
for various tests. But I think that has been fixed in master, or has a
pull request.

I would like to drop SHA1 support in testing/unstable anyway, so I
think we should merge those patches once they've all been merged.


Kurt

Bug#918727: [Pkg-openssl-devel] Bug#918727: openssl.cnf incompatible with libssl1.0.2, libssl1.0.0

[Simon McVittie]

On Tue, 14 Apr 2020 at 23:44:54 +0200, Sebastian Andrzej Siewior wrote:
> On 2019-01-08 20:17:42 [+], Simon McVittie wrote:
> > It should probably at least have a Breaks on libssl1.0.2, to protect
> > partial upgrades from stretch. Some release notes for users of
> > third-party software might also be useful. I realise it probably isn't
> > feasible to keep openssl.cnf compatible with all past and future versions.
> 
> I think that we are a little late for that.

If we weren't in 2019, we definitely are now... but there are things that
could usefully be done (in Debian or upstream) to stop this class of bug
from happening again next time the SONAME gets bumped.

> > It would perhaps be a good idea for future OpenSSL branches to
> > use a configuration file that's tied to the major version in their SONAME,
> > or otherwise parallel-installable? (openssl1.1.0.cnf, etc.)
> 
> I don't remember having a problem in Stretch where we had two libs but
> one file.

Presumably the configuration file happened to have avoided using any new
functionality/features/syntax that would make the older library unhappy?

I think setting defaults in the shared library itself would be more
robust, and if a configuration file to override that is necessary,
I still think a SONAME-specific configuration file would be more robust
than expecting all past, present and future OpenSSL branches to share one.

> However there the environment variable OPENSSL_CONF which can
> be set to a specific configuration file. Wouldn't that work if you
> bundle a specific library?

It works if you know about it, but ISVs that bundle their own copies of
libraries (OpenSSL, etc.) don't always even know how to do RPATHs and
LD_LIBRARY_PATH correctly, so their chance of getting library-specific
things right seems to be pretty much zero. (Thinking here of the number
of third-party games on Steam that bundle their own copy of libstdc++6,
which reliably breaks recent versions of Mesa...)

> > In Debian, since 1.1.1 (August 2018, if we don't count experimental),
> > /etc/ssl/openssl.cnf has made use of the ssl_conf mechanism to enforce
> > TLS1.2 as the minimum protocol, and 112-bit security (level 2) as
> > the minimum security level. This file is only installed if the openssl
> > package (containing the openssl command-line tool) is installed. However,
> > ca-certificates depends on openssl, so in practice basically all users
> > will have it.

I think setting the minimum protocol and security level from inside
the shared library would be more robust, particularly since having
libssl installed does not actually guarantee that openssl will also be
installed (a libssl user might be validating against known-good "pinned"
certificates or CAs, rather than the system-wide PKI trust store in
ca-certificates).

> > This affects libssl1.0.0 in the Steam Runtime installed by the non-free
> > steam package, and possibly other third-party software bundles.
> > ()
> 
> It appears to be fixed in Steam. Do you see the need any kind of an
> action here?

I hacked around it in the Steam Runtime's copy of libssl by making it
default to the equivalent of OPENSSL_CONF=/dev/null if the STEAM_RUNTIME
environment variable is set; but that doesn't help anyone with their
own bundled or statically linked libssl.

smcv

Bug#918727: [Pkg-openssl-devel] Bug#918727: openssl.cnf incompatible with libssl1.0.2, libssl1.0.0

[Sebastian Andrzej Siewior]

On 2019-01-08 20:17:42 [+], Simon McVittie wrote:
> It should probably at least have a Breaks on libssl1.0.2, to protect
> partial upgrades from stretch. Some release notes for users of
> third-party software might also be useful. I realise it probably isn't
> feasible to keep openssl.cnf compatible with all past and future versions.

I think that we are a little late for that.

> It would perhaps be a good idea for future OpenSSL branches to
> use a configuration file that's tied to the major version in their SONAME,
> or otherwise parallel-installable? (openssl1.1.0.cnf, etc.)

I don't remember having a problem in Stretch where we had two libs but
one file. However there the environment variable OPENSSL_CONF which can
be set to a specific configuration file. Wouldn't that work if you
bundle a specific library?

…
> Workaround: use OPENSSL_CONF=/dev/null when running software that depends
> on an older libssl.

Right.

> For context, libssl_conf.so never actually existed on disk, and
> isn't really meant to. In OpenSSL's approach to configuration,
> /etc/ssl/openssl.cnf configuration parameters cause loading of
> native-code modules, which can either be built-in to libcrypto or
> libssl, or real files on disk to be dlopen()ed (like the way Python's
> sys module is built-in to the interpreter, but its readline module is
> external). libssl_conf.so in the default library search path (!) is one
> of several names OpenSSL would try for the ssl_conf module - I think
> the reason it appears in the error message is that it's the last one to
> be tried.
> 
> Since 1.1.0 (commit 59b1696c), there is a ssl_conf module built-in to
> libssl. It moved into libcrypto in 1.1.1 (commit d8f031e8).
> 
> In Debian, since 1.1.1 (August 2018, if we don't count experimental),
> /etc/ssl/openssl.cnf has made use of the ssl_conf mechanism to enforce
> TLS1.2 as the minimum protocol, and 112-bit security (level 2) as
> the minimum security level. This file is only installed if the openssl
> package (containing the openssl command-line tool) is installed. However,
> ca-certificates depends on openssl, so in practice basically all users
> will have it.

exactly.

> This affects libssl1.0.0 in the Steam Runtime installed by the non-free
> steam package, and possibly other third-party software bundles.
> ()

It appears to be fixed in Steam. Do you see the need any kind of an
action here?

> smcv

Sebastian

Bug#918727: [Pkg-openssl-devel] Bug#918727: openssl.cnf incompatible with libssl1.0.2, libssl1.0.0

[Kurt Roeckx]

On Tue, Jan 08, 2019 at 08:17:42PM +, Simon McVittie wrote:
> Package: openssl
> Version: 1.1.1a-1
> Severity: important
> Control: found -1 1.1.1~~pre3-1
> Control: affects -1 steam
> 
> The openssl.cnf in the openssl package since 1.1.1~~pre3-1 is incompatible
> with libssl < 1.1.0 (I think that's the right cutoff point), either from
> a partial upgrade or bundled with third-party software.
> 
> It should probably at least have a Breaks on libssl1.0.2, to protect
> partial upgrades from stretch. Some release notes for users of
> third-party software might also be useful. I realise it probably isn't
> feasible to keep openssl.cnf compatible with all past and future versions.
[...]
> This affects libssl1.0.0 in the Steam Runtime installed by the non-free
> steam package, and possibly other third-party software bundles.
> ()

We can add a Breaks, but I'm not sure that's actually going to fix
anything for those non-free 3rd party things.


Kurt

Bug#918727: openssl.cnf incompatible with libssl1.0.2, libssl1.0.0

[Simon McVittie]

Package: openssl
Version: 1.1.1a-1
Severity: important
Control: found -1 1.1.1~~pre3-1
Control: affects -1 steam

The openssl.cnf in the openssl package since 1.1.1~~pre3-1 is incompatible
with libssl < 1.1.0 (I think that's the right cutoff point), either from
a partial upgrade or bundled with third-party software.

It should probably at least have a Breaks on libssl1.0.2, to protect
partial upgrades from stretch. Some release notes for users of
third-party software might also be useful. I realise it probably isn't
feasible to keep openssl.cnf compatible with all past and future versions.

It would perhaps be a good idea for future OpenSSL branches to
use a configuration file that's tied to the major version in their SONAME,
or otherwise parallel-installable? (openssl1.1.0.cnf, etc.)

Minimal reproducer:

* start from Debian testing (buster)
* unpack libssl1.0.2 1.0.2q-2, from unstable, and openssl 1.0.2j-1
  from snapshots.debian.org (the newest openssl.deb that still depended
  on libssl1.0.2) into ~/102
* then run:
  LD_LIBRARY_PATH=$HOME/102/usr/lib/x86_64-linux-gnu $HOME/102/usr/bin/openssl 
s_client example.com:443

Expected result: successful connection

Actual result:

Error configuring OpenSSL
140099788864256:error:25066067:DSO support routines:DLFCN_LOAD:could not load 
the shared library:dso_dlfcn.c:187:filename(libssl_conf.so): libssl_conf.so: 
cannot open shared object file: No such file or directory
140099788864256:error:25070067:DSO support routines:DSO_load:could not load the 
shared library:dso_lib.c:233:
140099788864256:error:0E07506E:configuration file 
routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:271:module=ssl_conf, 
path=ssl_conf
140099788864256:error:0E076071:configuration file routines:MODULE_RUN:unknown 
module name:conf_mod.c:212:module=ssl_conf

The same thing can be reproduced with libssl1.0.0 and openssl from jessie.

Workaround: use OPENSSL_CONF=/dev/null when running software that depends
on an older libssl.

For context, libssl_conf.so never actually existed on disk, and
isn't really meant to. In OpenSSL's approach to configuration,
/etc/ssl/openssl.cnf configuration parameters cause loading of
native-code modules, which can either be built-in to libcrypto or
libssl, or real files on disk to be dlopen()ed (like the way Python's
sys module is built-in to the interpreter, but its readline module is
external). libssl_conf.so in the default library search path (!) is one
of several names OpenSSL would try for the ssl_conf module - I think
the reason it appears in the error message is that it's the last one to
be tried.

Since 1.1.0 (commit 59b1696c), there is a ssl_conf module built-in to
libssl. It moved into libcrypto in 1.1.1 (commit d8f031e8).

In Debian, since 1.1.1 (August 2018, if we don't count experimental),
/etc/ssl/openssl.cnf has made use of the ssl_conf mechanism to enforce
TLS1.2 as the minimum protocol, and 112-bit security (level 2) as
the minimum security level. This file is only installed if the openssl
package (containing the openssl command-line tool) is installed. However,
ca-certificates depends on openssl, so in practice basically all users
will have it.

This affects libssl1.0.0 in the Steam Runtime installed by the non-free
steam package, and possibly other third-party software bundles.
()

smcv