Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8019359

To comment why not use no_renegotiation to reject client initiated renegotiation

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • P4
    • 8
    • 8
    • security-libs
    • 8
    • b98
    • Verified

    Description

      See http://mail.openjdk.java.net/pipermail/security-dev/2013-June/007996.html

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

      Attachments

        Issue Links

          Activity

            People

              xuelei Xuelei Fan
              xuelei Xuelei Fan
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: