Configure SSL Protocol versions in Carbon servers
Both the server and client can support multiple TLS versions. During the negotiation phase they come to a mutual agreement on the highest protocol version each supports and communicate over that. In your deployment you might want to configure the SSL/TLS protocol versions that the carbon servers support. You can do that as follows.
Lets describe this as in [1] which is written by Prabath Siriwardena when disabling SSLv3.
Open [product_home]/repository/conf/tomcat/catalina-server.xml
- Find the Connector configuration corresponding to TLS - usually this is having the port as 9443 and "sslProtocol" as TLS.
- If you are using JDK 1.6 then remove the attribute sslProtocol="TLS" from the above configuration and replace it with: sslEnabledProtocols="TLSv1"
- If you are using JDK 1.7 then remove the attribute sslProtocol="TLS" from the above configuration and replace it with: sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"
If you have enabled pass-thru transport in any WSO2 product (ESB, API Manager) - you also need to do the following configuration change.
Open [product_home]/repository/conf/axis2/axis2.xml
Find the transportReceiver configuration element for org.apache.synapse.transport.passthru.PassThroughHttpSSLListener
To test the pass-thru transport use the following command with the corresponding port.
Output before the fix
Output after the fix
This all works fine unless you wants to disable TLSv1 for Carbon servers in JDK 6 or in JDK 7. For JDK 6 this can be ignored since mostly this will not be used spawn carbon instances now.
For JDK 7 this will fail even for login since it uses httpclient for stubs and when it comes as a client Carbon servers support all TLS versions that JVM offer and there is no configuration to disable client supported TLS versions. But why it's failing for JDK 7 is by default, it only enables TLSv1 for client connections [2][3]. And we cannot disable "TLSv1" (using -Dhttps.protocols=TLSv1.1,TLSv1.2 which is the only option) for client connections at JVM level for jre 7. New option (-Djdk.tls.client.protocols=TLSv1.1,TLSv1.2) is available from jre 8 [3] and also TLSv1.2 is the default enable version for jre 8, So that won't be a problem if we are using jre 8.
[1] http://wso2.com/library/blog-post/2014/10/blog-post-poodle-attack-and-disabling-ssl-v3-in-wso2-carbon-4.2.0-based-products/
[2] https://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
[3] https://blogs.oracle.com/java-platform-group/entry/diagnosing_tls_ssl_and_https
Open [product_home]/repository/conf/axis2/axis2.xml
Find the transportReceiver configuration element for org.apache.synapse.transport.passthru.PassThroughHttpSSLListener
- If you are using JDK 1.6 - add the following parameter under transportReceiver. <parameter name="HttpsProtocols">TLSv1</parameter>
- If you are using JDK 1.7 - add the following parameter under transportReceiver. <parameter name="HttpsProtocols">TLSv1,TLSv1.1,TLSv1.2</parameter>
$ java -jar TestSSLServer.jar localhost 9443
To test the pass-thru transport use the following command with the corresponding port.
$ java -jar TestSSLServer.jar localhost 8243
Output before the fix
Supported versions: SSLv3 TLSv1.0 Deflate compression: no Supported cipher suites (ORDER IS NOT SIGNIFICANT): SSLv3 RSA_EXPORT_WITH_RC4_40_MD5 RSA_WITH_RC4_128_MD5 RSA_WITH_RC4_128_SHA RSA_EXPORT_WITH_DES40_CBC_SHA RSA_WITH_DES_CBC_SHA RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA_EXPORT_WITH_DES40_CBC_SHA DHE_RSA_WITH_DES_CBC_SHA DHE_RSA_WITH_3DES_EDE_CBC_SHA RSA_WITH_AES_128_CBC_SHA DHE_RSA_WITH_AES_128_CBC_SHA RSA_WITH_AES_256_CBC_SHA DHE_RSA_WITH_AES_256_CBC_SHA (TLSv1.0: idem)
Output after the fix
Supported versions: TLSv1.0 Deflate compression: no Supported cipher suites (ORDER IS NOT SIGNIFICANT): TLSv1.0 RSA_EXPORT_WITH_RC4_40_MD5 RSA_WITH_RC4_128_MD5 RSA_WITH_RC4_128_SHA RSA_EXPORT_WITH_DES40_CBC_SHA RSA_WITH_DES_CBC_SHA RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA_EXPORT_WITH_DES40_CBC_SHA DHE_RSA_WITH_DES_CBC_SHA DHE_RSA_WITH_3DES_EDE_CBC_SHA RSA_WITH_AES_128_CBC_SHA DHE_RSA_WITH_AES_128_CBC_SHA RSA_WITH_AES_256_CBC_SHA DHE_RSA_WITH_AES_256_CBC_SHA
This all works fine unless you wants to disable TLSv1 for Carbon servers in JDK 6 or in JDK 7. For JDK 6 this can be ignored since mostly this will not be used spawn carbon instances now.
For JDK 7 this will fail even for login since it uses httpclient for stubs and when it comes as a client Carbon servers support all TLS versions that JVM offer and there is no configuration to disable client supported TLS versions. But why it's failing for JDK 7 is by default, it only enables TLSv1 for client connections [2][3]. And we cannot disable "TLSv1" (using -Dhttps.protocols=TLSv1.1,TLSv1.2 which is the only option) for client connections at JVM level for jre 7. New option (-Djdk.tls.client.protocols=TLSv1.1,TLSv1.2) is available from jre 8 [3] and also TLSv1.2 is the default enable version for jre 8, So that won't be a problem if we are using jre 8.
[1] http://wso2.com/library/blog-post/2014/10/blog-post-poodle-attack-and-disabling-ssl-v3-in-wso2-carbon-4.2.0-based-products/
[2] https://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
[3] https://blogs.oracle.com/java-platform-group/entry/diagnosing_tls_ssl_and_https
Comments
Post a Comment