changeset 18570:9078dc28a187

8019359: To comment why not use no_renegotiation to reject client initiated renegotiation Reviewed-by: wetmore
author xuelei
date Thu, 27 Jun 2013 19:22:51 -0700
parents 0e46c17766b7
children 8e3cb3c46ae8
files jdk/src/share/classes/sun/security/ssl/ServerHandshaker.java
diffstat 1 files changed, 9 insertions(+), 1 deletions(-) [+]
line wrap: on
line diff
--- a/jdk/src/share/classes/sun/security/ssl/ServerHandshaker.java	Thu Jun 27 19:02:02 2013 -0700
+++ b/jdk/src/share/classes/sun/security/ssl/ServerHandshaker.java	Thu Jun 27 19:22:51 2013 -0700
@@ -281,7 +281,15 @@
 
         // Reject client initiated renegotiation?
         //
-        // Should not have any impact on server initiated renegotiation.
+        // If server side should reject client-initiated renegotiation,
+        // send an alert_handshake_failure fatal alert, not a no_renegotiation
+        // warning alert (no_renegotiation must be a warning: RFC 2246).
+        // no_renegotiation might seem more natural at first, but warnings
+        // are not appropriate because the sending party does not know how
+        // the receiving party will behave.  This state must be treated as
+        // a fatal server condition.
+        //
+        // This will not have any impact on server initiated renegotiation.
         if (rejectClientInitiatedRenego && !isInitialHandshake &&
                 state != HandshakeMessage.ht_hello_request) {
             fatalSE(Alerts.alert_handshake_failure,