Bug 468603 - Can not reliably wait for close_notify
Can not reliably wait for close_notify
Product: Fedora
Classification: Fedora
Component: nss (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kai Engert (:kaie)
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-10-26 13:14 EDT by Miloslav Trmač
Modified: 2008-11-03 13:05 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-11-03 13:05:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Don't expect any more data after receiving a close_notify (604 bytes, patch)
2008-10-26 13:14 EDT, Miloslav Trmač
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 462874 None None None Never

  None (edit)
Description Miloslav Trmač 2008-10-26 13:14:49 EDT
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):
Comment 1 Kai Engert (:kaie) 2008-11-03 12:42:44 EST
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.
Comment 2 Kai Engert (:kaie) 2008-11-03 12:48:41 EST
Comment 3 Miloslav Trmač 2008-11-03 13:05:33 EST
Added myself.  Thank you.

Note You need to log in before you can comment on or make changes to this bug.