Bug 468603 - Can not reliably wait for close_notify
Summary: Can not reliably wait for close_notify
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: nss
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kai Engert (:kaie) (inactive account)
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-26 17:14 UTC by Miloslav Trmač
Modified: 2008-11-03 18:05 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-11-03 18:05:33 UTC
Type: ---
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Mozilla Foundation 462874 0 None None None Never

Description Miloslav Trmač 2008-10-26 17:14:49 UTC
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):
nss-3.12.1.1-1.fc9

Comment 1 Kai Engert (:kaie) (inactive account) 2008-11-03 17:42:44 UTC
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) (inactive account) 2008-11-03 17:48:41 UTC
https://bugzilla.mozilla.org/show_bug.cgi?id=462874

Comment 3 Miloslav Trmač 2008-11-03 18:05:33 UTC
Added myself.  Thank you.


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