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.
---
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
