[s-macke]

When I execute an ldd at /usr/bin/ssh I get

  libssl.so.10 => /lib64/libssl.so.10
  libssl3.so => /lib64/libssl3.so
  libnss3.so => /lib64/libnss3.so

What puzzles me is that I am using libssl.so.10 and libssl3.so at the same time. libssl3.so belongs to the nss package and not to the openssl package. Am I affected?

[Beltalowda]

The libssl3.so shared object from NSS just has a similar name. This is very confusing, but NSS has been around for a long time, before OpenSSL became the de-facto standard (sort-of), and certainly long before OpenSSL 3, so now we're "stuck" with this confusion.

[s-macke]

Many thanks for the information! This is really confusing.

[xorcist]

It is very unlikely that this affects OpenSSH regardless. Only the cryptographic primitives are used from OpenSSL, and none of the complexity of the SSL functions. The cryptographic functions themselves are small and extremely well tested.

[fulafel]

OpenSSH (or commonly used variants thereof?) supports X.509 certificates, would they really reimplement that can of worms instead of using already linked libssl functions? Especially since on OpenSSH's home platform libssl is LibreSSL which they consider safer than OpenSSL.

Also, there already was one OpenSSL 3 crypto primitive caused vuln or at least security relevant bug in OpenSSH this year: https://thehackernews.com/2022/06/openssh-to-release-securit...

[fulafel]

Correcting myself: in the ssh-keygen manpage it says that the cert format is not X.509:

  Note that OpenSSH certificates are a different, and
       much simpler, format to the X.509 certificates used in ssl(8).

[s-macke]

I took ssh only as an example as curl has the same dependency.

But thanks to @Beltalowda it is obvious, that the lib64/openssl3 does not belong to openssl.