summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorwtc%google.com <devnull@localhost>2008-10-03 19:20:20 +0000
committerwtc%google.com <devnull@localhost>2008-10-03 19:20:20 +0000
commit553a3bc99cce634bc6428feaada2f876443aba22 (patch)
treee3aaad40097dfd51467f162167e201cb98e2ebde
parentbfcdeefd0537db5d7697f816c600c75b4bc91d18 (diff)
downloadnss-hg-553a3bc99cce634bc6428feaada2f876443aba22.tar.gz
Bug 456862: added a block comment to explain why we don't respond with a
close_notify alert after we receive a close_notify alert. Reordered the tests in ssl_SecureClose and ssl_SecureShutdown to make it clear that the tests in those two functions are almost the same. r=nelson.
-rw-r--r--security/nss/lib/ssl/sslsecur.c28
1 files changed, 26 insertions, 2 deletions
diff --git a/security/nss/lib/ssl/sslsecur.c b/security/nss/lib/ssl/sslsecur.c
index a8c8b74b7..c2bbadbc2 100644
--- a/security/nss/lib/ssl/sslsecur.c
+++ b/security/nss/lib/ssl/sslsecur.c
@@ -995,14 +995,38 @@ ssl_SecureConnect(sslSocket *ss, const PRNetAddr *sa)
return rv;
}
+/*
+ * The TLS 1.2 RFC 5246, Section 7.2.1 says:
+ *
+ * Unless some other fatal alert has been transmitted, each party is
+ * required to send a close_notify alert before closing the write side
+ * of the connection. The other party MUST respond with a close_notify
+ * alert of its own and close down the connection immediately,
+ * discarding any pending writes. It is not required for the initiator
+ * of the close to wait for the responding close_notify alert before
+ * closing the read side of the connection.
+ *
+ * The second sentence requires that we send a close_notify alert when we
+ * have received a close_notify alert. In practice, all SSL implementations
+ * close the socket immediately after sending a close_notify alert (which is
+ * allowed by the third sentence), so responding with a close_notify alert
+ * would result in a write failure with the ECONNRESET error. This is why
+ * we don't respond with a close_notify alert.
+ *
+ * Also, in the unlikely event that the TCP pipe is full and the peer stops
+ * reading, the SSL3_SendAlert call in ssl_SecureClose and ssl_SecureShutdown
+ * may block indefinitely in blocking mode, and may fail (without retrying)
+ * in non-blocking mode.
+ */
+
int
ssl_SecureClose(sslSocket *ss)
{
int rv;
if (ss->version >= SSL_LIBRARY_VERSION_3_0 &&
- ss->firstHsDone &&
!(ss->shutdownHow & ssl_SHUTDOWN_SEND) &&
+ ss->firstHsDone &&
!ss->recvdCloseNotify &&
ss->ssl3.initialized) {
@@ -1032,8 +1056,8 @@ ssl_SecureShutdown(sslSocket *ss, int nsprHow)
}
if ((sslHow & ssl_SHUTDOWN_SEND) != 0 &&
+ ss->version >= SSL_LIBRARY_VERSION_3_0 &&
!(ss->shutdownHow & ssl_SHUTDOWN_SEND) &&
- (ss->version >= SSL_LIBRARY_VERSION_3_0) &&
ss->firstHsDone &&
!ss->recvdCloseNotify &&
ss->ssl3.initialized) {