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

[Xuelei Fan]

On 6/28/2013 8:16 AM, Brad Wetmore wrote:
> Rearranging and tweaking a bit. What do you think of:
> 
> ---
> Reject client 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.
> ---
> 
Looks nice to me.

Xuelei

> Brad
> 
> 
> 
> 
> On 6/27/2013 4:51 PM, Xuelei Fan wrote:
>> On 6/28/2013 6:44 AM, Brad Wetmore wrote:
>>> continued, I forgot this next part.
>>>
>>>>> 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.
>>>
>> What do you think these words:
>>
>> "Please don't send a no_renegotiation warning alert. Warning message is
>> not very useful because in general the sending party cannot know how the
>> receiving party behave.  The server side need to reject client initiated
>> renegotiation proactively."
>>
>> Thanks,
>> Xuelei
>>
>>
>>
>>