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

[guenther+ldapdev@sendmail.com]

On Mon, 8 Oct 2007, Howard Chu wrote:
...
>> There are a number of ways this can be handled:
>> 1) change the client to wait until it sees the server's close_notify alert 
>> by
>>    replacing "SSL_shutdown( p->ssl );" in tls.c with the two lines:
>>         if (SSL_shutdown( p->ssl ) == 0)
>>             SSL_shutdown( p->ssl );
>>    (I have confirmed that this works.  As documented, the first call
>>    will return 1 if the server's close_notify has already been
>>    received, if not, the second call will block until it is received.)
>
> So if the server doesn't send one, the client will be stuck waiting forever?

It would also unblock if the server closed the connection.  One downside 
of this option that I thought of later is that it shifts the TCP 
CLOSE_WAIT state from the client to the server.  Fixing that would add 
more complexity to the sockbuf layer than this entire change is worth.

Having chatted with Kurt about this at the last IETF meeting and pondered 
failure modes, I'm no longer in favor of this option.


>> 2) change the client to not bother to send a close_notify alert when
>>    it's just going to close() the connection; change the server to not
>>    send a close_notify if it didn't get one.  <...>
>
> Sounds like a change in the SSL library, not something for us to worry 
> about.

Since "send a close_notify alert" == "call SSL_shutdown() for the first 
time", it would be a change in how the SSL library was used by libldap.

Anyway, this issue isn't worth keep an ITS open about, as it doesn't 
actually cause failures or visible errors.  I might someday chase down a 
clean way of implementing this second option, but only after the much more 
useful work of coming up with a reasonable API to let event-driven apps do 
STARTTLS without blocking.  Someday.


Philip Guenther