3 ms·

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 puz

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?

xorcist 4y ago
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 4y ago
  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-security-patch-for.html https://thehackernews.com/2022/06/openssh-to-release-securit...
  - fulafel 4y ago
    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 4y ago
  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.
Beltalowda 4y ago
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 4y ago
  Many thanks for the information! This is really confusing.

xorcist 4y ago

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 4y ago
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-security-patch-for.html https://thehackernews.com/2022/06/openssh-to-release-securit...
- fulafel 4y ago
  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 4y ago
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.

Beltalowda 4y ago

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 4y ago
Many thanks for the information! This is really confusing.