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

Brad Wetmore bradford.wetmore at
Sun Jun 30 18:00:54 PDT 2013


I also think this is an excellent suggestion.  Glad that you made it and 
Xuelei is considering it.  Sorry I didn't get a chance to respond before 
I left for the weekend.  There will be a bit of work to do in the 
current code to support abandoning a handshake, but shouldn't be too bad.


On 6/27/2013 5:51 PM, Xuelei Fan wrote:
> On 6/28/2013 8:05 AM, Bernd Eckenfels wrote:
>> Am 28.06.2013, 01:51 Uhr, schrieb Xuelei Fan < at>:
>>> "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."
>> Just for the record, I totally disagree. I would make the option a multi
>> value like "accept(default)|ignore|reject". Because you never can know
>> how the other side reacts. Ignoring renego requests is totally safe in
>> the spec and in a situation where you chose to turn off renogotiation by
>> clients you can have only two things:
>> a) clients continue to work when you ignore them
>> b) clients break
>> If you always terminate the connection there is no chance for some
>> clients to keep working.
> Great suggestion.  I will consider to add the new "ignore" option.
>> Today you can already achieve the termination of connection (by
>> disabling all ciphersuites after initial handshake). You dont need to
>> add code if you dont offer more (i.e. ignore) options.
> You're right here.  This new system property is just to make the work a
> little easier that developers won't need to touch the source code in
> applications.
>> Greetings
>> Bernd
>> PS: and regarding the naming a question, is "JSSE" the name of the Sun
>> implementaion or of the Specification?
> I intend to use it for specification. But the names in JSSE is a little
> confusing now (See Brad's response). We need to consolidate the naming
> style.
> Xuelei

More information about the security-dev mailing list