Re: 3.0 beta1 feedback about (shared) library names
On Tue, 22 Jun 2021 04:23:06 +0200, Michael Richardson wrote: > > WTF is libssl3.so? I still don't know, but: > > %dpkg -S /usr/lib/x86_64-linux-gnu/libssl3.so > libnss3:amd64: /usr/lib/x86_64-linux-gnu/libssl3.so > something up there that should be concerning, because maybe it will cause > confusion. Here's how to take a closer look at Debian packages: $ apt show libnss3 Package: libnss3 Version: 2:3.67-1 Priority: optional Section: libs Source: nss Maintainer: Maintainers of Mozilla-related packages Installed-Size: 4,173 kB Depends: libc6 (>= 2.14), libnspr4 (>= 2:4.12), libsqlite3-0 (>= 3.5.9) Conflicts: libnss3-1d (<< 2:3.13.4-2) Homepage: http://www.mozilla.org/projects/security/pki/nss/ Tag: role::shared-lib Download-Size: 1,316 kB APT-Manual-Installed: no APT-Sources: http://ftp.se.debian.org/debian unstable/main amd64 Packages Description: Network Security Service libraries This is a set of libraries designed to support cross-platform development of security-enabled client and server applications. It can support SSLv2 and v4, TLS, PKCS #5, #7, #11, #12, S/MIME, X.509 v3 certificates and other security standards. As you can see, libnss3 packages Mozilla's NSS project, not OpenSSL. I just had a look at the source of that package, and it makes it clear that libnss3.so is actually the NSS project's own name for their SSL library, so this isn't even a packaging problem. > But, having both "libssl-dev" and "libssl3-dev" installed at the same time is > going to be a problem. Not really. Programs that are built against OpenSSL's libraries will use the files from libssl-dev, and programs that are built against Mozilla's NSS libraries will use the files from libssl3-dev. Yes, I agree that it's unfortunate that the library names are so similar, because confusion. I understand that. > I think that the differences in ABI may be significant enough that you should > consider calling it "libssl3" and "libcrypto3". Yeah, maybe that's uncool, > but it may be pragmatic. It's not at all pragmatic, let alone not at all cool, seeing that libssl3 isn't ours. I hope you understand this at this point. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: How to query current settings/policies?
On Tue, Jun 22, 2021 at 02:53:07PM +0200, Tomas Mraz wrote: > On Tue, 2021-06-22 at 14:12 +0200, Thomas Deutschmann wrote: > > Hi, > > > > with OpenSSL 3 defaulting to TLS security level 1, applications > > trying > > to make a TLSv1/1.1 connection will fail. > > > > I wonder if there is a proper way to detect current security level. > > > > I.e. how about test suites which need to know if they have to skip a > > test or not? > > > > For example, I am currently looking at MySQL which has a test to > > ensure, > > that you are still able to connect to TLS 1.3 enabled server with > > TLSv1/1.1: > > https://github.com/mysql/mysql-server/blob/mysql-8.0.25/mysql-test/suite/auth_sec/t/tls13_tls1.test > > > > The test already knows about the fact that system could have > > restricted > > minimum TLS version, see > > https://github.com/mysql/mysql-server/blob/mysql-8.0.25/mysql-test/include/not_min_protocol_tlsv12.inc > > > > However, this solution isn't stable: It's just parsing some files > > from > > hard coded paths (what about OPENSSL_CONF environment variable?) and > > guesses. > > > > Furthermore it knows nothing about Gentoo Linux for example. But > > even > > with Ubuntu, you could have a policy in place which overrides set > > OPENSSL_TLS_SECURITY_LEVEL=2 from configure. > > > > Is there a way to use openssl CLI to query this information and > > allow > > test suites for example to skip tests on a more reliable way? Or > > what's > > the recommended way for tests? > > There is already such feature request: > https://github.com/openssl/openssl/issues/14570 > > Unfortunately it was not implemented in time for beta1 so this is now > Post 3.0 item. > > I would recommend explicitly setting security level 0 via a cipher > string when executing the test. I second the motion. If a test is sensitive to some setting of the code under test, then the test should set it. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: PGP signature
Re: How to query current settings/policies?
On Tue, 2021-06-22 at 14:12 +0200, Thomas Deutschmann wrote: > Hi, > > with OpenSSL 3 defaulting to TLS security level 1, applications > trying > to make a TLSv1/1.1 connection will fail. > > I wonder if there is a proper way to detect current security level. > > I.e. how about test suites which need to know if they have to skip a > test or not? > > For example, I am currently looking at MySQL which has a test to > ensure, > that you are still able to connect to TLS 1.3 enabled server with > TLSv1/1.1: > https://github.com/mysql/mysql-server/blob/mysql-8.0.25/mysql-test/suite/auth_sec/t/tls13_tls1.test > > The test already knows about the fact that system could have > restricted > minimum TLS version, see > https://github.com/mysql/mysql-server/blob/mysql-8.0.25/mysql-test/include/not_min_protocol_tlsv12.inc > > However, this solution isn't stable: It's just parsing some files > from > hard coded paths (what about OPENSSL_CONF environment variable?) and > guesses. > > Furthermore it knows nothing about Gentoo Linux for example. But > even > with Ubuntu, you could have a policy in place which overrides set > OPENSSL_TLS_SECURITY_LEVEL=2 from configure. > > Is there a way to use openssl CLI to query this information and > allow > test suites for example to skip tests on a more reliable way? Or > what's > the recommended way for tests? There is already such feature request: https://github.com/openssl/openssl/issues/14570 Unfortunately it was not implemented in time for beta1 so this is now Post 3.0 item. I would recommend explicitly setting security level 0 via a cipher string when executing the test. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]
How to query current settings/policies?
Hi, with OpenSSL 3 defaulting to TLS security level 1, applications trying to make a TLSv1/1.1 connection will fail. I wonder if there is a proper way to detect current security level. I.e. how about test suites which need to know if they have to skip a test or not? For example, I am currently looking at MySQL which has a test to ensure, that you are still able to connect to TLS 1.3 enabled server with TLSv1/1.1: https://github.com/mysql/mysql-server/blob/mysql-8.0.25/mysql-test/suite/auth_sec/t/tls13_tls1.test The test already knows about the fact that system could have restricted minimum TLS version, see https://github.com/mysql/mysql-server/blob/mysql-8.0.25/mysql-test/include/not_min_protocol_tlsv12.inc However, this solution isn't stable: It's just parsing some files from hard coded paths (what about OPENSSL_CONF environment variable?) and guesses. Furthermore it knows nothing about Gentoo Linux for example. But even with Ubuntu, you could have a policy in place which overrides set OPENSSL_TLS_SECURITY_LEVEL=2 from configure. Is there a way to use openssl CLI to query this information and allow test suites for example to skip tests on a more reliable way? Or what's the recommended way for tests? -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
