openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#9176) libldap support for TLSv1.3 Encrypted SNI
by ryan＠openldap.org 20 Feb '20

20 Feb '20

Full_Name: Ryan Tandy Version: master OS: Debian URL: Submission from: (NULL) (70.66.128.207) Submitted by: ryan ldap.google.com requires clients to support SNI and sends back an intentionally invalid certificate if it is not used. Affects libldap with both OpenSSL and GnuTLS. (Might want a separate ITS for each fix.) With OpenSSL: $ ./clients/tools/ldapsearch -H ldaps://ldap.google.com -x -d1 ldap_url_parse_ext(ldaps://ldap.google.com) ldap_create ldap_url_parse_ext(ldaps://ldap.google.com:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP ldap.google.com:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 216.239.32.58:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS read server hello TLS trace: SSL_connect:TLSv1.3 read encrypted extensions TLS trace: SSL_connect:SSLv3/TLS read server certificate request TLS certificate verification: depth: 0, err: 18, subject: /OU=No SNI provided; please fix your client./CN=invalid2.invalid, issuer: /OU=No SNI provided; please fix your client./CN=invalid2.invalid TLS certificate verification: Error, self signed certificate TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in error TLS: can't connect: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate). ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) With GnuTLS: $ ./clients/tools/ldapsearch -H ldaps://ldap.google.com -x -d1 ldap_url_parse_ext(ldaps://ldap.google.com) ldap_create ldap_url_parse_ext(ldaps://ldap.google.com:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP ldap.google.com:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 216.239.32.58:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS: peer cert untrusted or revoked (0x42) TLS: can't connect: (unknown error code). ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) When the client does not support SNI, this server sends back a dummy certificate: OU = "No SNI provided; please fix your client.", CN = invalid2.invalid which obviously does not validate. The same behaviour can be seen with "openssl s_client -noservername" or "gnutls-cli --disable-sni". For GnuTLS, we have to call gnutls_server_name_set(3) to enable SNI. The documentation notes that it should only be called with a DNS name, not with an IP address. I guess there's a corresponding call for OpenSSL. With GnuTLS, users can work around it for the short term by disabling TLSv1.3 via priority string, i.e.: LDAPTLS_CIPHER_SUITE='NORMAL:!VERS-TLS1.3' ./clients/tools/ldapsearch -H ldaps://ldap.google.com -x Not sure if the same can be done with OpenSSL.

1 0

(ITS#9175) ldapsearch segfault
by lhaley＠meditech.com 20 Feb '20

20 Feb '20

Full_Name: Lexi Haley Version: 02/20/2020 trunk commit 299fb490a27e7b0e5a60464e33f5ea04d00f0f7c OS: CYGWIN on Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (208.206.3.188) Using clients/tools/ldapsearch to interact with my company's active directory, and I receive a segfault, in libraries/liblbver/decode.c . the 'gist' of the command I executed was: ldapsearch.exe -h companyADserver -b cn=users,dc=company,dc=com -s sub '(cn=z*)' cn the gdb backtrace is (omitting all the (arg=val) items for brevity: #0 ber_get_stringbvl (...) at decode.c:445 #1 0x0000000100435781 in ber_scanf (...) at decode.c:820 #2 0x000000010041a605 in ldap_get_attribute_ber (...) at getattr.c:149 #3 0x0000000100401d93 in print_entry (...) at ldapsearch.c:1758 #5 0x000000010043bfd7 in main (...) at ldapsearch.c:1510 and digging around - here is what I see going on. in decode.c, during the ber_get_stringbvl function, the passed in b (aka cookie from caller), has the following values: {choice = BvOff, option = 0, siz = 1, off = 4294967296, result = 0x800055410} notice that off is 0x100000000 - a likely ridiculous (and thus a possible MAGIC) value. examining in ber_scanf, looking at the memory for the va_args - i.e. examining ap - I see (sure enough) 0x100000000... As a hacky temporary workaround - I added to my ber_get_stringbvl , before even pulling the tag: } res; + if (b->off == 0x100000000) + return LBER_DEFAULT; tag = ber_skip_tag( ber, &bv.bv_len ); I did try rewinding my source back to OPENLDAP_REL_ENG_2_4_40 (2014) and then to OPENLDAP_REL_ENG_2_4_30 (2012) - and both compilations still yielded the segfault error I described above. I'm afraid I do not know much about ldap or active directory - so I easily might be omitting something relevant, and/or completely missing the mark in different ways. Feel free to ask me for more information, and/or suggest what I might try out. Thanks, Lexi

1 0

Re: (ITS#8639) Remove support for LANMAN
by fumiyas＠osstech.co.jp 20 Feb '20

20 Feb '20

Hi, I've created a path for smbk5pwd to disable the insecure sambaLMPassword support by default. https://github.com/osstech-jp/openldap/commit/bba50bf6533d8f67dcbfc990b6b31… https://github.com/osstech-jp/openldap/commit/bba50bf6533d8f67dcbfc990b6b31… -- -- Name: SATOH Fumiyasu @ OSS Technology Corp. (fumiyas @ osstech co jp) -- Business Home: https://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/ -- PGP Fingerprint: BBE1 A1C9 525A 292E 6729 CDEC ADC2 9DCA 5E1C CBCA

1 0