Details
-
Bug
-
Resolution: Fixed
-
P4
-
8
-
b98
-
Verified
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.
>> 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.
Attachments
Issue Links
- relates to
-
JDK-7188658 Add possibility to disable client initiated renegotiation
- Resolved