search

greenbone / gvm-libs

Greenbone Vulnerability Management Libraries
GNU General Public License v2.0
85 stars 79 forks source link

libgvm: ldap authentification failure after upgrading to openssl 3.2.0 #800

Open tgurr opened 12 months ago

tgurr commented 12 months ago

Hope gvm-libs is the right place to report this issue as that's what is mentioned in the logs. After upgrading OpenSSL from 3.1.4 to the recently released 3.2.0 LDAP users are no longer able to login to the greenbone-security-assistant webinterface. Downgrading OpenSSL back to 3.1.4 allows the login to work again. OpenLDAP version installed is 2.6.6.

image

Expected behavior

Successful login for LDAP users.

Actual behavior

LDAP users are unable to login to greenbone-security-assistant after upgrading to OpenSSL 3.2.0 with the following log entry in /var/log/gvm/gvmd.log:

libgvm util:WARNING:2023-11-27 13h27.18 utc:18888: LDAP authentication failure: Can't contact LDAP server.
md    gmp:WARNING:2023-11-27 13h27.18 utc:18888: Authentication failure for 'xxx' from unix_socket

Steps to reproduce

  1. Upgrade to OpenSSL 3.2.0
  2. Restart the machine/services
  3. Try to login as LDAP user

GVM versions

gsa: Greenbone Security Assistant 22.08.0

gvm: Greenbone Vulnerability Manager 23.1.0

openvas: OpenVAS 22.7.7

gvm-libs: gvm-libs 22.7.3

Environment

Operating system: Linux

Installation method / source: Package from source-based distribution.

Logfiles

See above.

4D617274696E commented 12 months ago

Did you update to OpenSSL 3.2.0 on the Greenbone Community Edition host, or the LDAP server host, or both?

tgurr commented 12 months ago

Did you update to OpenSSL 3.2.0 on the Greenbone Community Edition host, or the LDAP server host, or both?

Sorry for not providing this information in my initial report, the upgrade (and downgrade again) was done solely on the Greenbone Community Edition host, the LDAP server host wasn't touched and is actually a Microsoft AD.

4D617274696E commented 12 months ago

Thanks! I have forwarded this internally, hopefully we'll have a look at it soon.

cfi-gb commented 12 months ago

If the OpenSSL version on the scanner host has been updated a possibility would be that the LDAP server host is only supporting "weak" ciphers or SSL/TLS protocol versions not supported anymore (by default) in OpenSSL 3.2:

The default SSL/TLS security level has been changed from 1 to 2.

https://www.openssl.org/news/openssl-3.2-notes.html

tgurr commented 12 months ago

If the OpenSSL version on the scanner host has been updated a possibility would be that the LDAP server host is only supporting "weak" ciphers or SSL/TLS protocol versions not supported anymore (by default) in OpenSSL 3.2:

The default SSL/TLS security level has been changed from 1 to 2. https://www.openssl.org/news/openssl-3.2-notes.html

That indeed appears to be the problem here, thanks for the hint.

openssl s_client -connect dc.domain.local:636 -showcerts -CAfile /<path>/Root_CA.pem returns:

openssl 3.1.4:

SSL-Session:
    Verify return code: 0 (ok)

openssl 3.2.0:

SSL-Session:
    Verify return code: 66 (EE certificate key too weak)
cfi-gb commented 11 months ago

More info from e.g. https://superuser.com/questions/1640089/ssl-certificate-ee-certificate-key-too-weak:

By default, Debian has configured OpenSSL at security level 2, which provides 112 bits of security. That means that if one of the keys involved in the TLS connection, in this case the server's key (the end-entity certificate), provides a security level less than 112 bits (usually because the certificate is an RSA key smaller than 2048 bits), then it will be rejected.

AFAICT this is not a problem on the software stack side and needs to be solved on the remote service (LDAP) side by creating new and more secure certificates.