From 071acd64cc6758afd16460340492a5ebdbd072e6 Mon Sep 17 00:00:00 2001
From: xuelei <unknown>
Date: Thu, 27 Jun 2013 19:22:51 -0700
Subject: [PATCH] 8019359: To comment why not use no_renegotiation to reject
 client initiated renegotiation Reviewed-by: wetmore

---
 .../classes/sun/security/ssl/ServerHandshaker.java     | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/share/classes/sun/security/ssl/ServerHandshaker.java b/src/share/classes/sun/security/ssl/ServerHandshaker.java
index 69c783247..e317e1f18 100644
--- a/src/share/classes/sun/security/ssl/ServerHandshaker.java
+++ b/src/share/classes/sun/security/ssl/ServerHandshaker.java
@@ -281,7 +281,15 @@ final class ServerHandshaker extends Handshaker {
 
         // 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,
-- 
GitLab