[jira] [Commented] (IGNITE-16627) SNI extension is missing when Java thin client is connecting to Ignite cluster with SSL enabled

["Semyon Danilov (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-16627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17701724#comment-17701724 ] 

Semyon Danilov commented on IGNITE-16627:
-----------------------------------------

The problem:

There is a SSL gateway proxy in k8s cluster. In order to connect to a node of the cluster, SNI extension must be provided. Otherwise SSL gateway doesn’t know where to route incoming traffic.

A thin client is located outside of the k8s cluster. It is aware of some address (probably the address of the gateway). As a WA a custom SSLFactory might be implemented, which provides SNI extension. However, this way thin client can only connect to one node (the one whose Server Name is provided). So when a client learns (through affinity awareness) of other nodes, it won’t be able to connect to them, outgoing traffic will always be routed to the first node with provided Server Name. This means that there’s a single point of denial and that load will be unbalanced.

Implementation problem(s):

According to the TLS protocol, we can only set one Server Name per connection. ATM we have one SSLContext per all connections. Looks like we need to have a context per connection. By default, we should set each address (if it is a hostname) from ClientConfiguration as a Server Name for a connection to that address. In case we are learning about a node “in runtime” – we should cycle through it’s addresses and use hostname as Server Name for connections. There can be a problem if we get an IP of a node (that will probably be the internal k8s cluster IP) – we most likely won’t be able to connect to it. However we should be able to connect by hostname

> SNI extension is missing when Java thin client is connecting to Ignite cluster with SSL enabled
> -----------------------------------------------------------------------------------------------
>
>                 Key: IGNITE-16627
>                 URL: https://issues.apache.org/jira/browse/IGNITE-16627
>             Project: Ignite
>          Issue Type: Bug
>          Components: thin client
>    Affects Versions: 2.11
>            Reporter: Maria Makedonskaya
>            Priority: Major
>
> Motivation: There are cases then ignite clients are connecting to a cluster which is located inside Kubernetes(k8s) and k8s cluster has an ingress gateway that routes TLS traffic using SNI extension.
> Need to provide hostnames from org.apache.ignite.configuration.ClientConfiguration#setAddresses to SNI extention. 
> SSLContext for java thin client is creating in org.apache.ignite.internal.client.thin.ClientSslUtils#getSslContext. Possibly we can use org.apache.ignite.ssl.SSLContextWrapper there to provide additional SSLParameters(like it's done in org.apache.ignite.ssl.SslContextFactory#createSslContext). For adding SNI extension need to add hostnames via javax.net.ssl.SSLParameters#setServerNames.
> Also need to check that other thin clients and thick clients add SNI to handshake.
> Possibly in org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter#onSessionOpened we need additionally to replace 
> from:
> {code:java}
> engine = this.sslCtx.createSSLEngine();{code}
> to:
> {code:java}
> engine = this.sslCtx.createSSLEngine(ses.remoteAddress().getHostName(), ses.remoteAddress().getPort()){code}
> In this case, if an IP address is set to ClientConfiguration#setAddresses then SNI extension will be added with reverse lookup hostname. If hostname with a port is set to ClientConfiguration#setAddresses no SNI extension will be added.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)