geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Deppe <jde...@pivotal.io>
Subject Re: Special certificates for multisite
Date Fri, 01 Nov 2019 18:07:19 GMT
Juan,

Let me try and answer just to ensure that *I* fully understand the use case.

>From an 'alias' POV this could be seen as having the ability for a *single*
component (locator, server, etc) to have multiple (dynamic) aliases. So,
depending on where the connection originated *from* a particular
certificate is chosen.

Currently we only have the ability to associate a single certificate with
an individual component.

--Jens

On Fri, Nov 1, 2019 at 10:51 AM Ju@N <jujoramos@gmail.com> wrote:

> Hello Alberto,
>
> I'm not particularly knowledgeable on this subject so I might be missing
> something, but with Geode you can independently configure SSL for specific
> system components, can't you just use multiple alias to achieve your use
> case as described here [1]?.
>
> *>> 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.*
> Here you would use *cluster *as the alias to configure the SSL settings
> used for communications within one geographical site, and *gateway *as the
> alias to configure the particular SSL settings to be used for
> communications across sites. Would that work for you?.
>
> Cheers.
>
> [1]:
>
> https://geode.apache.org/docs/guide/110/managing/security/implementing_ssl.html
>
>
> On Fri, Nov 1, 2019 at 1:37 PM Anthony Baker <abaker@pivotal.io> wrote:
>
> > Just checking, is anyone familiar enough with SSL to comment on the
> > proposed change?
> >
> > Anthony
> >
> >
> > > On Oct 29, 2019, at 2:44 AM, Mario Ivanac <mario.ivanac@est.tech>
> wrote:
> > >
> > > 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.
> > >
> > >
> > >
> >
> >
>
> --
> Ju@N
>

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