8019359: To comment why not use no_renegotiation to reject client initiated renegotiation
authorxuelei
Thu, 27 Jun 2013 19:22:51 -0700
changeset 18570 9078dc28a187
parent 18569 0e46c17766b7
child 18571 8e3cb3c46ae8
8019359: To comment why not use no_renegotiation to reject client initiated renegotiation Reviewed-by: wetmore
jdk/src/share/classes/sun/security/ssl/ServerHandshaker.java
--- 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,