Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-36250

Drop SSlv3 retry and copied CustomSSLProtocolSocketFactory.java from SAL

XMLWordPrintable

    • We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.

      The fix for CONF-24035 introduced a retry with SSLv3 if a connection fails. However, like workaround implemented in SAL-203 there is no need to retry with SSLv3 - instead enabling TLSv1.1 or higher will address the issue. The issue is actually caused by java not following the TLS rfc. When TLSv1.1 or higher is enabled or the system property com.sun.net.ssl.rsaPreMasterSecretFix is set to true java will as per the TLS specification send the same version it supports in the client hello and in the PreMasterSecret. Otherwise, the default behaviour when TLSv1.1 is not enabled in client mode (e.g. the default in java 7) is to send the highest enabled version in the client hello and the active negotiated version in the PreMasterSecret causing servers (tested against openssl) to reject java's connection.

      Note: Oracle has disabled SSLv3 in java 7 update 75 and java 8 update 31, see http://www.oracle.com/technetwork/java/javase/7u75-relnotes-2389086.html and http://www.oracle.com/technetwork/java/javase/8u31-relnotes-2389094.html respectively. So attempting to retry with SSlv3 will not work.

      Please fix this issue by removing the copied CustomSSLProtocolSocketFactory class (it was copied from SAL) and setting the HttpClientHttpRetrievalService.DEFAULT_SSL_PROTOCOL based upon what is available in the running JVM. Note: in my quick survey of confluence plugins there was not a single usage or reference the HttpClientHttpRetrievalService.DEFAULT_SSL_PROTOCOL field.

          Form Name

            [CONFSERVER-36250] Drop SSlv3 retry and copied CustomSSLProtocolSocketFactory.java from SAL

            Sen Geronimo made changes -
            Workflow Original: JAC Suggestion Workflow 4 [ 3579647 ] New: JAC Suggestion Workflow 3 [ 4329058 ]
            Katherine Yabut made changes -
            Workflow Original: JAC Suggestion Workflow 2 [ 3185780 ] New: JAC Suggestion Workflow 4 [ 3579647 ]
            Status Original: RESOLVED [ 5 ] New: Closed [ 6 ]
            Katherine Yabut made changes -
            Workflow Original: JAC Suggestion Workflow [ 3037202 ] New: JAC Suggestion Workflow 2 [ 3185780 ]
            Owen made changes -
            Workflow Original: Confluence Workflow - Public Facing v4 [ 2530155 ] New: JAC Suggestion Workflow [ 3037202 ]
            Rachel Lin (Inactive) made changes -
            Workflow Original: Confluence Workflow - Public Facing v3 [ 2260472 ] New: Confluence Workflow - Public Facing v4 [ 2530155 ]
            Katherine Yabut made changes -
            Workflow Original: Confluence Workflow - Public Facing v3 - TEMP [ 2198532 ] New: Confluence Workflow - Public Facing v3 [ 2260472 ]
            Katherine Yabut made changes -
            Workflow Original: Confluence Workflow - Public Facing v3 [ 1942398 ] New: Confluence Workflow - Public Facing v3 - TEMP [ 2198532 ]
            Katherine Yabut made changes -
            Workflow Original: Confluence Workflow - Public Facing v2 [ 1754738 ] New: Confluence Workflow - Public Facing v3 [ 1942398 ]
            jonah (Inactive) made changes -
            Description Original: The fix for CONF-24035 introduced a retry with SSLv3 if a connection fails. However, like workaround implemented in SAL-203 there is no need to retry with SSLv3 - instead enabling TLSv1.1 or higher will address the issue. The issue is actually caused by java not following the TLS rfc. When TLSv1.1 or higher is enabled or the system property {{com.sun.net.ssl.rsaPreMasterSecretFix}} is set to {{true}} java will as per the TLS specification send the same version it supports in the client hello *and* in the PreMasterSecret. Otherwise, the default behaviour when TLSv1.1 is not enabled in client mode (e.g. the default in java 7) is to send the highest enabled version in the client hello and the *active negotiated version* in the PreMasterSecret causing servers (tested against openssl) to reject java's connection.

            Note: Oracle has disabled SSLv3 in java 7 update 75 and java 8 update 31, see http://www.oracle.com/technetwork/java/javase/7u75-relnotes-2389086.html and http://www.oracle.com/technetwork/java/javase/8u31-relnotes-2389094.html respectively. So attempting to retry with SSlv3 will not work.

            Please fix this issue by removing the copied CustomSSLProtocolSocketFactory class (it was copied from SAL) and setting the HttpClientHttpRetrievalService.DEFAULT_SSL_PROTOCOL based upon what is available in the running JVM. Note: in my quick survey of confluence plugins there was not a single usage or reference the HttpClientHttpRetrievalService.DEFAULT_SSL_PROTOCOL field.             		New: {panel:bgColor=#e7f4fa}
              *NOTE:* This suggestion is for *Confluence Server*. Using *Confluence Cloud*? [See the corresponding suggestion|http://jira.atlassian.com/browse/CONFCLOUD-36250].
              {panel}

            The fix for CONF-24035 introduced a retry with SSLv3 if a connection fails. However, like workaround implemented in SAL-203 there is no need to retry with SSLv3 - instead enabling TLSv1.1 or higher will address the issue. The issue is actually caused by java not following the TLS rfc. When TLSv1.1 or higher is enabled or the system property {{com.sun.net.ssl.rsaPreMasterSecretFix}} is set to {{true}} java will as per the TLS specification send the same version it supports in the client hello *and* in the PreMasterSecret. Otherwise, the default behaviour when TLSv1.1 is not enabled in client mode (e.g. the default in java 7) is to send the highest enabled version in the client hello and the *active negotiated version* in the PreMasterSecret causing servers (tested against openssl) to reject java's connection.

            Note: Oracle has disabled SSLv3 in java 7 update 75 and java 8 update 31, see http://www.oracle.com/technetwork/java/javase/7u75-relnotes-2389086.html and http://www.oracle.com/technetwork/java/javase/8u31-relnotes-2389094.html respectively. So attempting to retry with SSlv3 will not work.

            Please fix this issue by removing the copied CustomSSLProtocolSocketFactory class (it was copied from SAL) and setting the HttpClientHttpRetrievalService.DEFAULT_SSL_PROTOCOL based upon what is available in the running JVM. Note: in my quick survey of confluence plugins there was not a single usage or reference the HttpClientHttpRetrievalService.DEFAULT_SSL_PROTOCOL field.
            jonah (Inactive) made changes -
            Link New: This issue relates to CONFCLOUD-36250 [ CONFCLOUD-36250 ]

              mtran@atlassian.com Minh Tran
              dblack David Black
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: