Notice in the RFC section you referenced:

_ It is not required for the initiator
   of the close to wait for the responding close_notify alert before
   closing the read side of the connection._

Judging from the comments, it seems we should just use GNUTLS_SHUT_WR instead of GNUTLS_SHUT_RDWR.


re: _Since openldap uses select you could use gnutls_bye with GNUTLS_SHUT_WR, and once the socket is readable try to read
with gnutls_record_recv() which should return 0 (EOF). If it is not readable within some time limit terminate the connection with error._

OpenLDAP only calls gnutls_bye during a session teardown, so the connection is already being terminated. Nobody is going to be attempting to read anything more from the socket at that point, there's no point in select'ing on it for readability.

I'm not sure what mechanism is used in OpenLDAP (I'm the developer of nss-pam-ldapd and I don't know too much about OpenLDAP internals). ITS#6673 has a backtrace that may be helpful though.

I suspect OpenLDAP uses a blocking socket and uses select() to do polling. As a user of the OpenLDAP API, the socket is mostly hidden for me. As a workaround for this problem I get the socket from OpenLDAP and use setsockopt() to set SO_RCVTIMEO and SO_SNDTIMEO.

I don't understand why you need to negotiate a disconnect though. If the TCP connection is severed for some reason or the other end is not responsive I don't see the extra security in trying to negotiate a disconnect. Am I missing something?

Anyway, thanks for your response.

Arthur

How do you shut down the connection?  gnutls_bye() needs to talk to the other server to negotiate a disconnect, otherwise things will be insecure (it was one of the security issues with SSLv2).

Does it really block if you set the socket in non-blocking mode?

/Simon