POODLE Attack and Disabling SSL V3 in WSO2 Carbon 4.2.0 Based Products

Early this week Google researchers announced that they have found a bug in the SSL 3.0 protocol. The exploit could be used to intercept critical data that’s supposed to be encrypted between clients and servers.

The exploit first allows attackers to initiate a “downgrade dance” that tells the client that the server doesn’t support the more secure TLS (Transport Layer Security) protocol and forces it to connect via SSL 3.0.

From there a man-in-the-middle attack can decrypt secure HTTP cookies.

POODLE

Google calls this the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack.

This means, even both your server and the client support TLS, still due to the downgrade attack, both the parties can be forced to use SSL 3.0. If any one of the party disables its support for SSL 3.0 - that will help to mitigate the attack.

Both Chrome and Firefox already announced that they are going to disable the SSL 3.0 support by default. Firefox 34, with SSL 3.0 disabled, will be released on 25th November. If you want to disable SSL 3.0 on firefox now, you can use the plugin SSL Version Control.

Chrome has already issued a patch to disable SSL 3.0.

Disable SSL V3 on WSO2 Carbon 4.2.0

Following explains how to disable SSL 3.0 support on WSO2 Carbon 4.2.0 based servers

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
If you are using JDK 1.6 - add the following parameter under transportReceiver.
If you are using JDK 1.7 - add the following parameter under transportReceiver.

Following explains how to validate the fix. You can download TestSSLServer.jar from here.

$ 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