Code review request, 7188658 Add possibility to disable client initiated renegotiation

[Matthew Hall]

I think it would be better if the property did use JSSE prefix, because other crypto providers will likely also want to adjust their own renegotiation behavior based on the value of the property. Thanks for contributing this useful security improvement to JSSE.

Matthew.
-- 
Sent from my mobile device.

Xuelei Fan <xuelei.fan at oracle.com> wrote:

>On 6/19/2013 10:50 AM, Brad Wetmore wrote:
>> Sorry for the delay.
>> 
>> Two comments about the property name.
>> 
>> I don't see the jdk.tls *System* Property prefix used anywhere else,
>> except as a *Security* properties:
>> 
>>     jdk.tls.rejectClientInitializedRenego
>> 
>> Otherwise, I think we should stick to one of the current namespace.
>> 
>>     jsse.               (my preference since this is expected across
>>                          other JDKs)
>>     sun.security.ssl.
>> 
>At the beginning, I use the prefix "jsse.*". But it is rejected (CCC)
>because the system property has no effect on other providers. Now, two
>styles are acceptable. "jdk.*" is for JDK properties, and "jsse.*" is
>used when other parties also should follow it. "sun.security.ssl" is
>deprecated, I think.
>
>> Regarding rejectClientInitializedRenego, I think the word "Initiated"
>> more succinctly captures the intent of this property, rather than
>> "Initalized."  And as long as the word "Renegotiation" is, it should
>> probably be spelled out completely.  AFAIK, we rarely abbreviate
>> external names like this.
>> 
>> Same "initiated" comment about the variable name in your codereview,
>but
>> I don't care much about Renogo.
>> 
>I prefer "Initiated" to "Initalized".  Let's make the update in another
>update.
>
>> 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.
>
>> This TLS logic decision is not straightforward, so this needs
>commenting.
>> 
>I think "reject client initialized renegotiation" has say all. ;-) I
>will add words about "state != HandshakeMessage.ht_hello_request".
>
>
>> 379:  since you're making changes here.
>> 
>>   response->respond
>> 
>OK.
>
>> Since you already have CCC approval and are ready to putback, I would
>> suggest putting back now, and let's file another CCC to change the
>name.
>>  That should be a no-brainer.
>> 
>OK.
>
>Thanks,
>Xuelei
>
>> Thanks!
>> 
>> Brad
>> 
>> 
>> 
>> 
>> 
>> On 5/29/2013 7:05 PM, Xuelei Fan wrote:
>>> Got it. Yes, this fix is addressing a different issue from you
>mentioned
>>> below.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>> On 5/30/2013 9:53 AM, Bernd Eckenfels wrote:
>>>> Am 30.05.2013, 02:18 Uhr, schrieb Xuelei Fan
><xuelei.fan at oracle.com>:
>>>>>> 2381456
>>>>> Would you mind send me the link of the bug, or the code review
>request
>>>>> mail?  I may miss some mails about this direction.
>>>>
>>>> I am afraid I cant sent the link, the Bug is in review state and
>>>> therefore not visible for me. It was acknowledged 2012-11-12, see
>>>> attached. I guess the link would be
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2381456 (not
>sure if
>>>> the numbers are the same in the new bug tool).
>>>>
>>>>> Good suggestion.  Oracle provider of JSSE had addressed the TLS
>>>>> renegotiation issue in JDK 1.4.2 update 26, JDK 1.5.0 update 24
>and JDK
>>>>> 6u 19 around the end of 2009 and the beginning of 2010.  Here is
>the
>>>>> readme of the fix:
>>>>>
>http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html.
>>>>>
>>>>>
>>>>
>>>> Thats a different problem, I was thinking about preventing
>execessive
>>>> client initiated renegotiations. This is for example CVE-2011-1473
>from
>>>> THC.
>>>>
>>>>>> You mentioned industry will move to a secure handshake - are you
>>>>>> aware of any initiative in that direction?
>>>>>>
>>>>> See http://www.rfc.org/rfc/rfc5746.txt.  As far as I know, nearly
>all
>>>>> major vendors of SSL protocols has support RFC5746.
>>>>
>>>> Ok, but thats a different issue. I was expecting 7188658 to address
>>>> another point, but I might be wrong.
>>>>
>>>> I understand that as of Oracle policy we cannot discuss it. Even if
>this
>>>> is a very well known issue. :-/
>>>>
>>>> Greetings
>>>> Bernd
>>>