Package: ldap-utils Version: 2.4.23-7.2 Severity: normal In the process of trying to troubleshoot a problem with TLS, I noticed in a packet trace that if the client (in this case ldapsearch) receives a FIN,ACK during TLS negotiation, it will follow up with a client key exchange TLS1.1 pakcet instead of merely ACKing the FIN. This of course is met with a RST from the server.
This happens if the client (ldapsearch) sends a 0-length certificate during TLS negotiation and the server (slapd) is configured to require client authentication and thus drops the connection. Here is a sample tshark output: 13 0.009511 ldap2 ldaps ldap1 48191 TLSv1.1 Certificate Request, Server Hello Done .... a few ACKs 17 0.014107 ldap1 48191 ldap2 636 TLSv1.1 Certificate 18 0.014180 ldap2 ldaps ldap1 48191 TCP ldaps > 48191 [FIN, ACK] Seq=2386 Ack=106 Win=5792 Len=0 TSV=106129855 TSER=706880134 19 0.015260 ldap1 48191 ldap2 636 TLSv1.1 Client Key Exchange 20 0.015282 ldap2 ldaps ldap1 48191 TCP ldaps > 48191 [RST] Seq=2387 Win=0 Len=0 I can provide a full tshark -w capture file if needed. -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ldap-utils depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libgnutls26 2.8.6-1 the GNU TLS library - runtime libr ii libldap-2.4-2 2.4.23-7.2 OpenLDAP libraries ii libsasl2-2 2.1.23.dfsg1-7 Cyrus SASL - authentication abstra Versions of packages ldap-utils recommends: ii libsasl2-modules 2.1.23.dfsg1-7 Cyrus SASL - pluggable authenticat ldap-utils suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org