EDIT
The BEAST mitigation has been solved. Turns out we simply ovelooked a configuration option. By overlooking it, I had many false assumptions about the TLS v1.2 option, so I’ve crossed those out below. The SP 800-131 Strict Mode option is not perfect IMO, but it’s not a requirement for us anyway (at this point).
At my customer, they are trying to mitigate the BEAST (Browser Exploit Against SSL/TLS, CVE-2011-3389) for BFI 9.2.14. The basic way to mitigate this is to require TLS 1.2 for browser connections. The solution should be simple, but we are finding that this is prohibitively complicated for BFI..
Background
The current version of the BFI docs say that TLS 1.2 is already enabled by default since 9.2.13 in the “Enabling TLS 1.2 in IBM Java” section.
9.2.13 Starting from application update 9.2.13, TLS 1.2 is enabled in IBM Java by default.
Link: IBM Documentation
The next step is to ensure the server requires TLS 1.2. The docs say this is done by turning on NIST SP 800-131 compliance. How to do this is described in the “Enabling SP800-131 compliance” section of the docs.
Enable the Java Secure Socket Extension (JSSE) to run in SP800-131 strict mode: set the system property com.ibm.jsse2.sp800-131 to strict. The property must be set in the jvm.options file, which is in the installation_dir/wlp/usr/servers/server1 directory.
Link: IBM Documentation
The Problem
Upon doing this, the BFI tema.log shows that the server cannot start due to various errors, the root cause of which is the inability to connect to the MS SQL Server:
SRVE0292I: Servlet Message - [tema]:.[ERROR] Cannot connect to the database: Java::ComMicrosoftSqlserverJdbc::SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "SQL Server did not return a response. The connection has been closed.
The design of the SP 800-131 strict mode assumes that the server is being started with a remote DB connection which must be encrypted. In many cases, BFI actually runs with a local database that’s already protected on the server from external connections. These installations of MS SQL Server are not configured for TLS 1.2, so the connection attempt from strict-mode BFI cannot establish encryption with a trusted certificate. The end result is BFI cannot launch without it’s database connection.
What Can Be Done?
At this point, I don’t know. Does anyone have any ideas?.
For customers who want to mitigate the BEAST exploit, all that’s required is to require TLS 1.2 for browser connections. TLS 1.2 for encrypting database and SSO connections are not required to mitigate BEAST, so I think an approach that’s different from the “all or nothing” SP 800-131 strict mode should be considered.
Aside from editing the jvm.options file like how the current BFI docs describe for strict TLS 1.2 enforcement, there appear to be other ways of requiring TLS 1.2 in WebSphere. Maybe one of those will work? I hope these can be explored by developers as a possible solution. For example:
https://developer.ibm.com/answers/questions/206952/how-do-i-configure-websphere-application-server-ss.html
Other Factors
An additional benefit to only requiring TLS 1.2 for a browser connection is no performance hit to MS SQL Server connections. I don’t know exactly what the performance impact is of encrypting local DB connections, but it certainly is extra work that’s unnecessary for the server to do.
Furthermore, I do not know how SP 800-131 strict mode will affect SSO integration with AD FS where HTTP is used. If the SP 800-131 mode blocks this, then nobody at my customer will be able to use BFI.