Code review request, 7188658 Add possibility to disable client initiated renegotiation (original) (raw)
Xuelei Fan xuelei.fan at oracle.com
Thu Jun 27 23:51:15 UTC 2013
- Previous message (by thread): Code review request, 7188658 Add possibility to disable client initiated renegotiation
- Next message (by thread): Code review request, 7188658 Add possibility to disable client initiated renegotiation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 6/28/2013 6:44 AM, Brad Wetmore wrote:
continued, I forgot this next part.
ServerHandshaker.java ===================== 283: My initial thought was a norenegotiation(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 norenegotiation 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
- Previous message (by thread): Code review request, 7188658 Add possibility to disable client initiated renegotiation
- Next message (by thread): Code review request, 7188658 Add possibility to disable client initiated renegotiation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]