On Sat, May 16, 2020 at 2:25 AM Christoph Berg <m...@debian.org> wrote:
> > Somebody should get out the LDAP RFCs and decode the packet contents
> > that this log helpfully provides, but I suspect that we're just looking
> > at an authentication failure; there's still not much clue as to why.
>
> The non-TLS tests work, so it's not a plain auth failure...
>
> I'm attaching the full logs from that test, maybe someone with more
> insight can compare the non-TLS with the TLS bits.
>
> Would it help to re-run that with log_debug on the PG side?
In your transcript for test 20, it looks like the client (PostgreSQL)
is hanging up without even sending a TLS ClientHello:
tls_read: want=5, got=0
...
psql:TLS: can't accept: The TLS connection was non-properly terminated..
With 001_auth.tl hacked to enable debug as you suggested*, on a local
Debian 10 system I see:
tls_read: want=5, got=5
0000: 16 03 01 01 4c ....L
That's: 0x16 = handshake record, 0x03 0x01 = TLS 1.0, and then a
record length for the following ClientHello. You're not even getting
that far, so I guess libdap is setting up the connection but then the
GNU TLS library (what Debian links libldap against) is not happy, even
before any negotiations begin. I wonder how to figure out why... does
this tell you anything?
$ENV{'LDAPCONF'} = $ldap_conf;
+$ENV{"GNUTLS_DEBUG_LEVEL"} = '99';
* Like this:
-system_or_bail $slapd, '-f', $slapd_conf, '-h', "$ldap_url $ldaps_url";
+system("$slapd -d 255 -f $slapd_conf -h '$ldap_url $ldaps_url' &");
