69726 - SSL connections seldom shut down cleanly

Status: NEW

(NSS :: Libraries, defect, P3)

Description

[Nelson Bolyard (seldom reads bugmail)]

NSS's SSL/TLS code always sends a "close notify" alert 
immediately prior to closing the socket, if the connection
has previously begun (or completed) an SSL3/TLS handshake.  

I believe it was the original intent of the SSL 3 creators
that close notify alerts records would perform the same 
function at the SSL layer that FIN does in the TCP protocol,
and that both ends would be required to send it prior to 
normal shutdown.  That's why this code behaves as it does.

But commonly, the first side of the TLS connection to initiate
connection closure sends a close-notify alert and then immediately
closes the socket, making the socket unable to receive a 
close-notify alert in response from the other side.  If the other
sides replies to the close-notify alert by sending another close-
notify alert, it will typically receive a TCP RST response from
its peer.

So, I propose to change NSS's SSL/TLS code to remember if it 
has received a Close-Notify alert from the other side, and 
not send one prior to close if it has already received one.

This may improve performance.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

The SSL code already remembers if it has read a close notify alert.
But it doesn't use that info when deciding whether or not to send
a close notify alert.

However, there's another problem. Unless there's a handshake in 
progress, NSS only reads from the socket when the application 
calls one of the read/recv functions.  So, it is possible that
a close notify alert has been received (at the TCP level), but
hasn't been read from the kernel's TCP buffers because the 
application hasn't done a read.  If the application does a
write, it will experience the TCP RST described above.

To really solve this problem requires adding recv buffering
into the SSL code, something we have not historically done
out of concerns for memory usage.  

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Maybe someday the "gather" engines will be re-written.  Then this bug
can be reconsidered.

Comment 3

[Wan-Teh Chang]

Changed the QA contact to Bishakha.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

I agree that comment 4 was apparently placed into the wrong bug.  
I will mark the misplaced comment "private" to reduce confusion.