Red Hat Bugzilla – Bug 468603
Can not reliably wait for close_notify
Last modified: 2008-11-03 13:05:33 EST
Created attachment 321552 [details]
Don't expect any more data after receiving a close_notify
Description of problem:
I need to implement a "nested", temporary TLS session on a connection (running unencrypted at first, then TLS, then again unencrypted). I'm using SSL_ImportFD(PR_ImportTCPSocket(dup(mysocket))) to create a NSS SSL socket.
Switching from unencrypted to encrypted works fine, but to switch back I need to reliably detect when the TLS session has ended.
When any of the sides closes the SSL socket, nss sends a close_notify alert, but it does not wait until it receives a close_notify alert from the other side.
Ideally there should be an interface that lets me do this (see (man SSL_shutdown) to see how OpenSSL handles it) - please consider this a feature request.
Because the second unencrypted communication is unidirectional in my case, I decided to PR_Close() the socket in the writer (and ignore any incoming close_notify), and to PR_Recv() in the reader, which should return 0 upon receiving the close_notify.
PR_Recv() actually processes the close_notify, but then waits for more data anyway, consuming data from the unencrypted communication.
The attached patch fixes the receive side to stop reading data after receiving a close_notify, which is sufficient for my current application - but please add a general interface to reliably shut down the TLS session.
Version-Release number of selected component (if applicable):
Your patch changes the core of NSS / SSL behavior.
I'm reluctant to apply such a patch in our own systems, only.
I propose to report your proposal in an upstream bug to the NSS project.
I'll create such a bug, forwarding your comments and patch.
I'll mention the bug number in the next comment.
It would be great if you could cc yourself to the upstream bug, and contribute in the discussion over there.
Added myself. Thank you.