Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Indicated we are always setting the SNI hostname

...

poolFactory.setSocketFactory(ProxySocketFactories.sni("proxyHostname", 443));


In order for this proxy to work, the SNI hostname field in the TLS handshake must be set to the name of the locator or server we are trying to connect to. With a slightly larger SocketFactory interface, we could potentially only send this SNI hostname when an SNI proxy is configured. However, we propose that the Geode client will always send the SNI hostname field as part of the handshake. We feel adding the SNI hostname will only be helpful to users, who may decide to use to to present different SSL certificates for different hostnames, or other use cases for this hostname.


Below are the details on the new methods and interfaces added to the API to support this

Modified classes:

...

This is a client side setting so there should be no backwards compatibility or upgrade concerns with the setting. We are sending a new piece of information as part of the TLS handshake, but this is a TLS extension and it will be ignored by servers and locators.

One concern with this SocketFactory approach is that is including the use of blocking, Java 1.0 sockets in the API. If in the future we try to upgrade the internals of the client to use SocketChannel or netty or rsocket, we will have a difficult time continuing to support this SocketFactory API and may break users' custom SocketFactory implementations.

...

Geode also added support to set the SNI field hostname in the client hello as part of GEODE-7414. With those changes a user can provide a SSLParameterExtension callback that can modify any of the SSLParameters including the SNI fieldhostname. If a proxy of type SNI is set and the SSLParameterExtension is also set, the SSLParameterExtension will run after geode has set the SNI fieldhostname, and can potential modify it.

...