JDK-8019359 : To comment why not use no_renegotiation to reject client initiated renegotiation
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 8
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-06-28
  • Updated: 2013-07-11
  • Resolved: 2013-06-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8 b98Fixed
Related Reports
Relates :  
Description
See http://mail.openjdk.java.net/pipermail/security-dev/2013-June/007996.html

>> ServerHandshaker.java
>> =====================
>> 283:  My initial thought was a no_renegotiation(100) warning, but that
>> allows the client to decide what to do, rather than the server terminating.
>>
> No, we cannot.  First of all, warning message is not very useful because
> in general the sending party cannot know how the receiving party behave.
>   Secondly, it is the expected behavior to *reject" client initiated
> renegotiation. It is the server who should make the decision, but not
> the client.

Exactly.

>> This TLS logic decision is not straightforward, so this needs commenting.

And the above is what I wanted to see in the comments.  That is, why we don't send a no_renegotiation warning alert.  It's a subtle but important enough point that should be documented.  I think we should open a separate bug to handle this.  Just a couple of lines are needed.

Comments
Add comments for the code ,code looks good.
09-07-2013