GemFire 9.6 SSL Endpoint Validation

Products

• VMware Tanzu Gemfire

Issue/Introduction

Symptoms:
GemFire 9.6 added the option to enable endpoint validation in SSL connections. This feature is turned on by setting the GemFire property, "ssl-endpoint-identification-enable", to "true". However, this enhanced security carries with it some additional complexities.

By enabling this feature, it is very likely you will encounter errors like the following:

[severe 2019/05/14 09:03:58.329 EDT locator1 <FederatingManager1> tid=0x3d] SSL Error in connecting to peer /10.0..0.10[55555].
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address 10.0.0.10 found
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
        at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1964)

Environment

Cause

These errors are most likely due to a certificate that does not conform to the more stringent requirements for endpoint validation introduced in a fix in Java 8u51 (JDK-8067694):

"With this fix, JSSE endpoint identification does not perform reverse name lookup for IP addresses by default in JDK.

If an application does need to perform reverse name lookup for raw IP addresses in SSL/TLS connections, and encounter endpoint identification compatibility issue, System property "jdk.tls.trustNameService" can be used to switch on reverse name lookup. Note that if the name service is not trustworthy, enabling reverse name lookup may be susceptible to MITM attacks."

Note: Despite the verbiage, this "susceptibility to MITM attacks" is still less likely with endpoint validation enabled and reverse lookups allowed, versus without any endpoint validation.

Resolution

GemFire will use both hostnames and IP addresses within communications, the servers' certificates either need to have the IP addresses properly included in the SAN (SubjectAlternativeNames) list or the SSL library needs to be configured to do reverse lookups (using the system property mentioned above, "jdk.tls.trustNameService").

Note: There is an open internal ticket to replace the repeated logging of the warning message about not having "ssl-endpoint-identification-enabled" set to true with a single instance of the warning, so if your only motivation is to eliminate the flood of "Your SSL configuration disables hostname validation" messages, waiting for and using a version of GemFire with a fix for GEM-2502 might be your best option. However, that option is not available yet (as of GemFire 9.8) and would only apply to running with hostname validation turned off (the old behavior).

To run with hostname validation enabled, you have two options:

1. You can set the Java system property "jdk.tls.trustNameService=true" (by adding something like `--J="-Djdk.tls.trustNameService=true"` to your startup options). This option allows reverse DNS lookups and should allow GemFire to work with your certs unchanged but, in theory, it could also allow a man-in-the-middle attack.

Note: It is better than running without hostname validation as before, but not perfect.

2. You can add the IP address(es) of the host to the certificate's SAN list. This will require generating modified certificates for your cluster. Moreover, it appears that some underlying SSL libraries are particular about how this is done and will not consistently accept IP addresses in the SAN that are stored as "DNSName" type entries --- you should put the IP addresses in the SAN as both type "IPAddress" and type "DNSname".