Cipher compatibility issue with default IngressController configuration in FIPS mode

[terenceq]

No cipher suite in common with Semeru runtime and default IngressController configuration

This problem can be seen when a Java client (for example a connection from the Manage all or mea containers) attempts a connection to the auth route. An example is a connection from a Java client using IBM Semeru to the URL:

https://<auth route>/oidc/endpoint/MaximoAppSuite/token"

The default tlsSecurityPolicy that is configured for the IngressController does not contain a cipher in common with IBM Java Semeru when running in FIPS mode. A proposed solution is to configure the tlsSecurityProfile in a similar fashion as what is done for the APIServer. For example:

 tlsSecurityProfile:
   custom:
     ciphers:
       - TLS_AES_128_GCM_SHA256
       - TLS_AES_256_GCM_SHA384
       - TLS_CHACHA20_POLY1305_SHA256
       - ECDHE-ECDSA-AES128-GCM-SHA256
       - ECDHE-RSA-AES128-GCM-SHA256
       - ECDHE-ECDSA-AES256-GCM-SHA384
       - ECDHE-RSA-AES256-GCM-SHA384
       - ECDHE-ECDSA-CHACHA20-POLY1305
       - ECDHE-RSA-CHACHA20-POLY1305
       - DHE-RSA-AES128-GCM-SHA256
       - DHE-RSA-AES256-GCM-SHA384
       - ECDHE-RSA-AES128-SHA256
       - ECDHE-RSA-AES128-SHA
       - ECDHE-RSA-AES256-SHA
     minTLSVersion: VersionTLS12
   type: Custom

The above configuration should be added to the IngressController resource (usually named default)

An interesting observation is that out of the box on Fyre when FIPS was enabled the IngressController did not seem to be enforcing the default profile of Intermediate. However, as soon as the Intermediate policy was set Semeru clients running in FIPS mode could no longer connect to the auth route.

Again for reference see the docs here:

https://docs.openshift.com/container-platform/4.12/security/tls-security-profiles.html#tls-profiles-ingress-configuring_tls-security-profiles

[terenceq]

Just to follow up - if the cipher incompatibility with Java Semeru clients comes up in other places the following unhelpful stack trace might appear (this one is from a Java client using Apache HttpClient):

Exception in thread "main" javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
    at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
    at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
    at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:340)
    at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:293)
    at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:186)
    at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
    at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1507)
    at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1417)
    at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:456)
    at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:427)
    at org.apache.hc.client5.http.ssl.SSLConnectionSocketFactory.executeHandshake(SSLConnectionSocketFactory.java:303)
    at org.apache.hc.client5.http.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:275)
    at org.apache.hc.client5.http.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:251)
    at org.apache.hc.client5.http.impl.io.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:181)
    at org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager.connect(BasicHttpClientConnectionManager.java:399)
    at org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:162)
    at org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:172)
    at org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:142)
    at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
    at org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
    at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
    at org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:96)
    at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
    at org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:152)
    at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
    at org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:115)
    at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
    at org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:170)
    at org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:245)
    at org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:188)
    at org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:162)
    at ClientTester.main(ClientTester.java:120)

If it is further debugged a handshake error will happen directly after the ClientHello and not progress any further. That is right after the ClientHello you will see something like:

javax.net.ssl|DEBUG|01|main|2023-07-28 24:10:14.345 UTC|SSLSocketInputRecord.java:494|Raw read (
  0000: 15 03 03 00 02                                     .....
)
javax.net.ssl|DEBUG|01|main|2023-07-28 24:10:14.345 UTC|SSLSocketInputRecord.java:214|READ: TLSv1.2 alert, length = 2
javax.net.ssl|DEBUG|01|main|2023-07-28 24:10:14.345 UTC|SSLSocketInputRecord.java:494|Raw read (
  0000: 02 28                                              .(
)
javax.net.ssl|DEBUG|01|main|2023-07-28 24:10:14.345 UTC|SSLSocketInputRecord.java:247|READ: TLSv1.2 alert, length = 2
javax.net.ssl|DEBUG|01|main|2023-07-28 24:10:14.346 UTC|Alert.java:238|Received alert message (
"Alert": {
  "level"      : "fatal",
  "description": "handshake_failure"
}
)

[andrercm]

Hi @terenceq any suggestions on who can take over this work? Not sure who's working more closely with FIPS at the moment... @whitfiea any thoughts?

[terenceq]

@andrercm I can go ahead and work on this one.

[andrercm]

@terenceq can we close this issue? i see there was a PR merged around this.

[istrate]

@terenceq @andrercm Should this have been closed?