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

guenther+ldapdevsendmail.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/hy
c/
   Chief Architect, OpenLDAP     http://www.openldap.
org/project/