Problem

Resolution

In order to keep being able to communicate with your partner via HTTP over SSL using TLS only, you will need to install at least service pack of 5.10.1, SP11. Due to the SSLv3 POODLE vulnerability, Interchange's default behavior changes in SP11 to only use and accept the TLS protocol per default. We would strongly recommend to install the latest service pack.

Please note that by doing this, all your SSL/TLS will communications will be via TLS only as well, which means you will need to inform for partners regarding this change as well, so they can take appropriate actions themselves.

Please also see the SP11 readme, about those changes:

------------------------------------

[Security Vulnerability] SSL3 "Poodle" vulnerability reported; Interchange and Secure Relay applications could be vulnerable (CVE-2014-3566)

Before: Interchange clients and servers using SSL connections were susceptible to the Poodle vulnerability issue. This was due to the fact that the SSLv3 protocol was enabled alongside with TLSv1. The impacted transports were HTTPS (both UI and trading), FTPS and PeSIT. Other transports, like OFTP TLS, were already restricted to only use TLSv1 and were not vulnerable.

After: The SSLv3 protocol is now disabled by default for all client and server SSL connections and only TLSv1 is available. This applies to all transports mentioned above (HTTPS UI and trading, FTPS, PeSIT, OFTP) and for all possible DMZ configurations: without DMZ, Outbound through DMZ with and without "Begin secure connection in DMZ", and Inbound through DMZ with and without "Enable security termination in DMZ".

In order to enable SSLv3 again, the property sslProtocols from /conf/tuning.properties can be used. This must contain a list of protocol names separated by commas where the accepted values are SSLv2Hello, SSLv3, and TLSv1. This property is global to all transports and applies to both clients and servers. So it will not be possible to enable SSLv3 only in client mode, or only for a specific transport type. Note that even when all protocols are specified, the list is still further filtered for each transport in part as required. For example, OFTP TLS only supports TLSv1 while PeSIT only supports SSLv3 and TLSv1. When a wrong value is specified for the property, Interchange will revert back to using only TLSv1.

The tuning.properties value is read only once, when the Interchange server is starting. If the value is changed, a restart is needed to apply it.

Examples for configuring the global property:

• sslProtocols=SSLv2Hello,SSLv3,TLSv1
• sslProtocols=SSLv3,TLSv1
• sslProtocols=TLSv1 -> identical to the default behavior, when the property is not specified at all

Note that the Java 6 implementation used by Interchange will send SSLv3/TLS ClientHellos encapsulated in a SSLv2 ClientHello, as long as SSLv2Hello is enabled. If the other side does not support SSLv2Hello, the handshake will fail. So only enable SSLv2Hello in the sslProtocols property when the partners also support it

More info about this can be found at Java Secure Socket Extension (JSSE) - https://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallProbs

Troubleshooting -> Configuration Problems -> Socket Disconnected after Sending ClientHello Message:

[...]some older server implementations speak only SSLv3 and do not understand TLS. Ideally, these implementations should negotiate to SSLv3, but some simply hangup. For backwards compatibility, some server implementations (such as SunJSSE) send SSLv3/TLS ClientHellos encapsulated in a SSLv2 ClientHello packet. Some servers do not accept this format; in these cases, use setEnabledProtocols to disable the sending of encapsulated SSLv2 ClientHellos.