Re: (ITS#4940) libldap doesn't wait for server's TLS close_notify

[hyc@symas.com]

guenther+ldapdev@sendmail.com wrote:
> Full_Name: Philip Guenther
> Version: 2.3.27
> OS: Linux and Solaris
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (64.58.1.252)
> 
> 
> [I vaguely recall seeing a report of this issue in the archives of one of the
> mailing lists, but I can no longer find the original.]
> 
> If you trace the packets sent when you use, for example, ldapsearch against a
> server on a different host, using either the -Z option to do TLS or using an
> ldaps URI, you'll discover that the TCP connection is actually reset instead of
> being closed cleanly: the client sends TCP RSTs in response to the server's
> final packets.
> 
> This is because libldap uses the following sequence when unbind a TLS or SSL
> connection:
> 1) send the unbind request (over the TLS or SSL layer)
> 2) call SSL_shutdown(), sending the TLS close_notify alert
> 3) call close()
> 
> After receiving the close_notify alert from step (2), the server sends back its
> own close_notify alert and then calls close().  However, because the client
> didn't wait for the server's response before calling close() on its end, the
> client's TCP stack considers the TCP connection to already be gone and responds
> with the RST packets.  This occurs with Linux and Solaris clients and probably
> most other unices: the response to packets after a close() doesn't vary in my
> experience.

That sounds like you're seeing a bug in the kernel's TCP stack then. A 
TCP close sends a FIN to the other end and is required to wait for the 
FIN to be ACK'd before the connection can be torn down. (Subject to 2MSL 
timeout.) That is most certainly not our problem.

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/