-
Bug
-
Resolution: Duplicate
-
Medium
-
None
-
5.6.6
-
None
The fix for CONF-24035 hard-codes SSLv3 and TLSv1 protocols and explicitly retries with SSLv3 which is not needed. The SSLv3 communication problem in java & confluence is actually caused by java changing its 'client_version' in the TLS handshake. This can be fixed by setting the ' com.sun.net.ssl.rsaPreMasterSecretFix' system property to 'true' or by enabling TLSv1.1 or higher (in java 7+). See https://ecosystem.atlassian.net/browse/SAL-280 & https://ecosystem.atlassian.net/browse/SAL-299.
I suggest that this issue be fixed by updating SAL and using the httpclient SAL provides instead of creating a new instance. Note: because of SAL-300 if confluence wants to support SSLv3 then it will need to set the https.protocols system property to one that contains SSLv3. We suggest not enabling SSLv3 as it is an old and insecure protocol.
- duplicates
-
CONFSERVER-36250 Drop SSlv3 retry and copied CustomSSLProtocolSocketFactory.java from SAL
- Closed
- relates to
-
-
- Closed
-
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[CONFSERVER-36731] The fix for CONF-24035 hard-codes SSLv3 and TLSv1 protocols and explicitly retries with SSLv3 which is not needed
Is this bug the reason we had to re-enable SSLv3 within our java security config, after upgrading to jdk1.7.0_80?
$JAVA_HOME/jre/lib/security/java.security #jdk.tls.disabledAlgorithms=SSLv3
When attempting to use the HTML Include macro for an HTTPS URL, it would not work until we commented out this line, despite the fact that if you hit the same URL in a browser, it was encrypted with TLS.
Yes that's possible because of how java behaves as a client in TLS versions less than 1.1. You may find that you can disable SSLv3 if you set com.sun.net.ssl.rsaPreMasterSecretFix system property to true. This tells java to follow the RFC TLS rules regarding client handshake versions for TLSv1, for more information see https://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html.