glassfish
  1. glassfish
  2. GLASSFISH-15695

Log a useful message when secure renegotiation isn't supported by the current peer.

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1_b38
    • Fix Version/s: 3.1_b39
    • Component/s: grizzly-kernel
    • Labels:
      None

      Description

      See http://java.net/jira/browse/GRIZZLY-962 for details on the issue as well as the proposed fix.

        Activity

        Hide
        Ryan Lubke added a comment -

        How bad is its impact? (Severity)

        • Likely to generate a customer support call

        How often does it happen? (Frequency)

        Any time a session renegotiation occurs on the server (running 1.6.0_22 or above) and the peer does not have a fix
        for [1].

        How much effort is required to fix it? (Cost)

        Minimal. All the fix accomplish is logging a message along the lines of:
        "GRIZZLY0081: Secure SSL/TLS renegotiation is not supported by the peer. This is most likely due to the peer using an older SSL/TLS implementation that does not resolve security vulnerability CVE-2009-3555"

        We should probably document this exception stating that the peer VM should be 1.6.0_22 or if the peer is a native application, it should have its SSL libraries
        updated.

        What is the risk of fixing it? (Risk)
        Minimal (see the changes in the referenced issue for details)

        Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
        Yes. See [2]. However, doing so opens up the security hole that was fixed by not allowing insecure renegotiations.

        If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
        If this improved message isn't present, then we'll need to at least document what the default exception message/stacktrace
        looks like and again, present the options of upgrading the peer, or opening the security hole back up.

        [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555
        [2] http://download.java.net/jdk7/docs/technotes/guides/security/jsse/JSSERefGuide.html#tlsRenegotiation

        Show
        Ryan Lubke added a comment - How bad is its impact? (Severity) Likely to generate a customer support call How often does it happen? (Frequency) Any time a session renegotiation occurs on the server (running 1.6.0_22 or above) and the peer does not have a fix for [1] . How much effort is required to fix it? (Cost) Minimal. All the fix accomplish is logging a message along the lines of: "GRIZZLY0081: Secure SSL/TLS renegotiation is not supported by the peer. This is most likely due to the peer using an older SSL/TLS implementation that does not resolve security vulnerability CVE-2009-3555" We should probably document this exception stating that the peer VM should be 1.6.0_22 or if the peer is a native application, it should have its SSL libraries updated. What is the risk of fixing it? (Risk) Minimal (see the changes in the referenced issue for details) Does a work around for the issue exist? Can the workaround be reasonably employed by the end user? Yes. See [2] . However, doing so opens up the security hole that was fixed by not allowing insecure renegotiations. If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes? If this improved message isn't present, then we'll need to at least document what the default exception message/stacktrace looks like and again, present the options of upgrading the peer, or opening the security hole back up. [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 [2] http://download.java.net/jdk7/docs/technotes/guides/security/jsse/JSSERefGuide.html#tlsRenegotiation
        Hide
        Chris Kasso added a comment -

        Is this essentially telling the peer that one side has a security vulnerability?

        Are you sure we should advertise this? I'm pretty sure this goes against our security policies.

        Show
        Chris Kasso added a comment - Is this essentially telling the peer that one side has a security vulnerability? Are you sure we should advertise this? I'm pretty sure this goes against our security policies.
        Hide
        Ryan Lubke added a comment -

        We don't communicate anything to the peer (the side that has the issue). This info goes the the server log only.

        Do you have pointers to the policies of what we can/can't log?

        Show
        Ryan Lubke added a comment - We don't communicate anything to the peer (the side that has the issue). This info goes the the server log only. Do you have pointers to the policies of what we can/can't log?
        Hide
        Ryan Lubke added a comment -

        Instead of referring to the security vulnerability issue, we could instead refer to RFC 5746. This RFC address the issue.

        So say the peer doesn't support RFC 5746.

        Show
        Ryan Lubke added a comment - Instead of referring to the security vulnerability issue, we could instead refer to RFC 5746. This RFC address the issue. So say the peer doesn't support RFC 5746.
        Hide
        Chris Kasso added a comment -

        If this is all within a GF cluster and only the server's logs then we are probably OK. I was concerned about the case where a client (acting as a peer) could poke the server looking for this message to determine that the server may be vulnerable. If that is not possible then we're probably OK.

        The security policies go so far as to say that we should not even advertise version numbers such that a hacker could probe for downrev versions in order to stage an attack.

        Show
        Chris Kasso added a comment - If this is all within a GF cluster and only the server's logs then we are probably OK. I was concerned about the case where a client (acting as a peer) could poke the server looking for this message to determine that the server may be vulnerable. If that is not possible then we're probably OK. The security policies go so far as to say that we should not even advertise version numbers such that a hacker could probe for downrev versions in order to stage an attack.
        Hide
        Chris Kasso added a comment -

        Approved for 3.1

        Show
        Chris Kasso added a comment - Approved for 3.1
        Hide
        Ryan Lubke added a comment -

        Sending packager/resources/pkg_conf.py
        Sending pom.xml
        Transmitting file data ..
        Committed revision 44729.

        Show
        Ryan Lubke added a comment - Sending packager/resources/pkg_conf.py Sending pom.xml Transmitting file data .. Committed revision 44729.

          People

          • Assignee:
            Ryan Lubke
            Reporter:
            Ryan Lubke
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: