geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivanac <mario.iva...@est.tech>
Subject Special certificates for multisite
Date Tue, 29 Oct 2019 09:44:54 GMT
Hi,

We are trying to find a solution for an situation we have. Below is the explanation of the
issue, as well as a proposed way forward. We would appreciate comments from the community
regarding this approach. Also, suggestions for a different approach to solve this issue would
be welcome.

The situation is the following: when SSL is enabled, we would like to use multiple certificates
in locators and servers: one certificate for communication inside one geographical site, and
another for the communication happening between geographical sites. The approach we took is
to use the default SSL context and implement our own Java Security Provider.

The client side can, from the security provider, easily distinguish which certificate to use
(just check if you are initiating a connection towards an IP listed in gemfire.remote-locators).
The thing we are missing is a criteria based on which we can choose the certificate on the
server side of the connection. Explanation: Once the handshake starts, a ClientHello message
is sent from the peer acting as a client in that connection (be it a geode server or a geode
locator). When the ClientHello is received on the server side, we can’t always read the
real originating IP (keeping the originating IP is sometimes not possible in cloud native
environments), so we can’t be sure whether the message originated from the same geographical
site or from another. We are left only with the information inside the ClientHello message.
The default ClientHello message doesn’t contain information based on which we can conclude
which site the message came from and which certificate to use.

Our proposal is to add the server_name extension in the ClientHello message. The content of
that extension would be the distributed system ID of the site where the ClientHello originated.
This way we could compare the distributed system ID in the ClientHello message with the ID
of the site where the message is received.

One issue with this approach is that the usage of the extension wouldn’t be completely in
line with the RFC<https://tools.ietf.org/html/rfc6066#page-6> description: we would
be inserting client information instead of the targeted server name. Still, since this extension
is otherwise of no use in Geode, and this approach doesn’t present a security risk (we would
be sharing the distributed system ID, which doesn’t look dangerous), we see this as a potential
way to go.




Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message