The history of SSL/TLS in the enterprise has been a dramatic one over the past decade or so. In 2014, the IT world was rocked by the discovery of a serious security vulnerability called POODLE, affecting what was then the de facto standard for communication encryptions, SSLv3. Information transmitted around the world from systems that had been running for almost two decades (SSLv3 was finalized in 1996!) often without any attention paid to their security postures were suddenly exposed to anyone with the right scripts or tools. The ensuing scramble to get systems remediated left many administrators tired, and frustrated, and determined to avoid a similar situation in the future.
For IT security in general the result of that event, combined with the subsequent barrage of additional cheekily-named SSL/TLS vulnerabilities (Sloth, Bar Mitzvah, and Logjam, just to name a few) has driven more pre-emptive approaches to security. Big-name servers and clients (browsers) alike have increasingly adopted newer and stronger encryption schemes as they become available, rather than waiting for old ones to become outmoded first. To a certain extent, malicious actors have found new techniques to keep pace with these practices, but overall the situation for end-user data security has improved substantially.
The POODLE situation prompted most shops to at least upgrade from SSLv3 to TLSv1, a specification that was finalized in 1999. Since then, the focus has been largely around moving to TLSv1.2 (finalized in 2008) due to the large number of enhancements and expanded cipher suite support in that version. TLSv1.3 (finalized in 2018) builds on those enhancements even further, and software across the industry, especially on the client (browser) side, has been much more aggressive about implementing it.
Starting in version 8.0.6.25, IBM Java 8 now includes support for the TLSv1.3 protocol, and because WebSphere runs on Java 8, WebSphere includes support for TLSv1.3 as well starting in fixpacks 9.0.5.6 and 8.5.5.20. Support for TLSv1.3 is provided through the IBMJCEPlus provider, which is now present in the default Java Security provider configuration in the java.security file starting in IBM Java 8.0.6.25. By default, WebSphere will still use the IBM Java "SSL_TLSv2" protocol string, which defaults to TLSv1.2 for outbound, and supports TLSv1.0, TLSv1.1, and TLSv1.2 for renegotiation and for inbound connections.
I'd like to highlight just a few of the TLSv1.3 protocol's improvements that I think are most important for WebSphere administrators. TLSv1.3 has...
- Removed support for certain cipher suites that use weak hashing functions and/or weak elliptic curves
- Added support for newer, stronger cipher suites, including those which use the ChaCha20 stream cipher and Poly1305 MAC
- Mandated perfect forward secrecy (PFS)
Right now, WebSphere supports TLSv1.3 when it is defined as the only protocol in a given SSL Configuration. This means that TLSv1.3 should only be configured in node-scoped SSL Configurations (for example, the default NodeDefaultSSLSettings configuration) in environments where all inbound and outbound connections support TLSv1.3 and do not require older protocols such as TLSv1.2. To configure TLSv1.3 at a given node-scope, adjust the Protocol setting in the Quality of Protection panel for the node's NodeDefaultSSLSettings configuration, and then update each profile's ssl.client.props file with the TLSv1.3 protocol to ensure that all of the WAS client processes can access the server. For ND environments, make sure to also update the CellDefaultSSLSettings to use TLSv1.3 so that the nodes and Deployment Manager can communicate. Note that there is an open RFE for setting TLSv1.3 with TLSv1.2 fallback -- please vote on this RFE if it is a feature that would be of value to your organization:
https://cloud-platform.ideas.ibm.com/ideas/TWAS-I-236In environments where only outbound TLSv1.3 is required, the recommended approach is to set up a Dynamic Outbound SSL Configuration. More information on that process here: https://www.ibm.com/docs/en/was/9.0.5?topic=csc-associating-ssl-configuration-dynamically-outbound-protocol-remote-secure-endpoint
As an aside, the Java 8.0.6.25 update brings a few other noteable enhancements and caveats that are important to keep in mind, even though they are not directly related to TLSv1.3.
- The IBMJCEPlus provider includes a significant performance uplift compared to the classic IBMJCE provider. Even for environments that are not migrating to TLSv1.3 just yet, it is recommended to use IBMJCEPlus for maximum performance.
- The JSSE trace (-Djavax.net.debug=all) format has been enhanced to the level present in Oracle Java 11. This brings a number of readability enhancements, but most importantly it also enhances the trace to show whether Java (WAS) is consuming or producing certain elements of the handshake, such as the ClientHello and the ServerHello. This is particularly useful on busy servers, for example where there may be a large number of inbound handshakes, but only one outbound handshake that needs to be debugged. For an extremely detailed overview of not only the new trace format, but also the general structure of JSSE, I would highly recommend checking out Oracle's JSSE reference guide: https://docs.oracle.com/en/java/javase/11/security/java-secure-socket-extension-jsse-reference-guide.html
- The IBMJCEFIPS provider will no longer be certified going forward. Instead, the newer and more performant IBMJCEPlusFIPS provider is now being certified. Currently WebSphere only supports IBMJCEFIPS, and this may cause issues depending on which WAS fixpack is in use. Please see the following TechNote for details: https://www.ibm.com/support/pages/node/6216059
- The FIPS cipher suites SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA and SSL_RSA_FIPS_WITH_DES_CBC_SHA have been removed. This could cause issues in WebSphere installations that are configured with these cipher suites. Before upgrading, ensure that these cipher suites are not defined as the only available cipher suites in any of the WAS SSL configurations.
Some additional reference links that might come in handy:
- The full TLSv1.3 RFC: https://datatracker.ietf.org/doc/html/rfc8446
- IBM Java Security release notes for 8.0.6.x: https://www.ibm.com/docs/en/sdk-java-technology/8?topic=wn-service-refresh-6
- IBM Java 8 fix list: https://www.ibm.com/support/pages/java-sdk-fixes-version-80
#Security#WebSphereApplicationServer(WAS)#whatsnew