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

Xuelei Fan xuelei.fan at oracle.com
Thu Jun 27 17:51:09 PDT 2013


On 6/28/2013 8:05 AM, Bernd Eckenfels wrote:
> Am 28.06.2013, 01:51 Uhr, schrieb Xuelei Fan <xuelei.fan at oracle.com>:
>> "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