Project

General

Profile

Bug #11626

Google LDAP connection failed due to lack of SNI for TLS 1.3

Added by Viktor Gurov 2 months ago. Updated 6 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Authentication
Target version:
-
Start date:
03/05/2021
Due date:
% Done:

0%

Estimated time:
Release Notes:
Default
Affected Plus Version:
21.02
Affected Architecture:

Description

https://forum.netgate.com/topic/161725/google-ldap-connection-failed:

I have a problem after update my Netgate XG-7100 to the version 21.02-RELEASE-p1.
After the update my pfSense failed to bind to ldap.google.com.

Attempting connection to ldap.google.com OK
Attempting bind to ldap.google.com failed

openldap24-client doesn't support SNI:

# 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)

https://support.google.com/a/answer/9190869?hl=en:

Verify return code: 18 (self signed certificate)

The Secure LDAP service requires a TLS client that supports and initiates a TLS session using SNI (Server Name Indication). If the TLS client does not support SNI, then the TLS server (ldap.google.com) returns a self-signed certificate that will not pass CA validation checks, to indicate that SNI is required.

This behavior can be confirmed by checking the OpenSSL client output for the following line near the start of the output:

depth=0 OU = "No SNI provided; please fix your client.", CN = invalid2.invalid

Causes for this error may include an OpenSSL version that does not support SNI, or an application that uses the OpenSSL library with SNI explicitly disabled.

PHP issue: https://stackoverflow.com/questions/65885108/sni-issues-connecting-to-google-ldap-server
ldapsearch issue: https://www.openldap.org/lists/openldap-bugs/202002/msg00421.html

History

#1 Updated by Viktor Gurov 2 months ago

may be related to #9417

#2 Updated by Jim Pingle 2 months ago

If OpenLDAP ldapsearch fails directly it's unlikely to be related to #9417

All the references I see to SNI seem fairly recent, but I'm not sure if they changed something on the Google side or if something on the client side changed (e.g. now using TLS 1.3 where it couldn't before).

#4 Updated by Jim Pingle 2 months ago

  • Project changed from pfSense to pfSense Plus
  • Subject changed from google LDAP connection failed to Google LDAP connection failed due to lack of SNI for TLS 1.3
  • Category changed from Authentication to Authentication
  • Affected Version deleted (2.5.0)
  • Affected Plus Version set to 21.02

Not that I like the idea of downgrading to a lower TLS version but I wonder if it would work if we forced off TLS 1.3 in this case using something like this:

ldap_set_option(NULL, LDAP_OPT_X_TLS_CIPHER_SUITE, "NORMAL:!VERS-TLS1.3");

I haven't tried that option so I'm not sure if it's one that needs NULL in that first spot like the cert setup or if it can take $ldap for per-connection options.

If that does work we could add a GUI knob to disable TLS 1.3 for LDAP, maybe only when sending a client cert.

#5 Updated by Alders Watne 6 days ago

Theoretically that would be the fix (forcing TLSv1.2 to bypass the SNI TLS v1.3 requirement), but setting this LDAP option or even with the old `putenv('LDAPTLS_CIPHER_SUITE=NORMAL:!VERS-TLS1.3')` doesn't work.

Same with `LDAPTLS_CIPHER_SUITE=NORMAL:!VERS-TLS1.3 ldapsearch -H ldaps://ldap.google.com -x -d1`.

Any ideas?

Jim Pingle wrote:

Not that I like the idea of downgrading to a lower TLS version but I wonder if it would work if we forced off TLS 1.3 in this case using something like this:

[...]

I haven't tried that option so I'm not sure if it's one that needs NULL in that first spot like the cert setup or if it can take $ldap for per-connection options.

If that does work we could add a GUI knob to disable TLS 1.3 for LDAP, maybe only when sending a client cert.

#6 Updated by Jim Pingle 6 days ago

It would either be this:

ldap_set_option(NULL, LDAP_OPT_X_TLS_CIPHER_SUITE, "NORMAL:!VERS-TLS1.3");

Or this:

ldap_set_option($ldap, LDAP_OPT_X_TLS_CIPHER_SUITE, "NORMAL:!VERS-TLS1.3");

And likely set just before or after the places LDAP_OPT_X_TLS_REQUIRE_CERT is set in /etc/inc/auth.inc.

#7 Updated by Alders Watne 6 days ago

The error self-signed error is gone but the bind still is unsuccessful. Same config ported over the 2.4 release line. Nothing specific about the error in the logs.

Jim Pingle wrote:

It would either be this:

[...]

Or this:

[...]

And likely set just before or after the places LDAP_OPT_X_TLS_REQUIRE_CERT is set in /etc/inc/auth.inc.

Also available in: Atom PDF