Re: Special certificates for multisite

[Jens Deppe]

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  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  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 
> 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
>

Re: Special certificates for multisite

[Jacob Barrett]

I have the same concern so I’d like to see the effort expended to be on making 
this pluggable. What in our current implementation needs to change so that 
someone can plug in an alternative implementation. The default being what we do 
now and the alternative using this extension the way you want. Another 
alternative would be Jen’s hypothetical user.

-Jake


> On Nov 1, 2019, at 9:21 AM, Jens Deppe  wrote:
> 
> I think it sounds pretty reasonable. Given that the only change to Geode
> would be the suggested update to the ClientHello and we shouldn't need to
> make any additional changes in order to leverage the functionality.
> Presumably the custom Provider would need to be installed by the user and
> configured for use in the JDK's java.security file.
> 
> The only downside would be if someone ever came up with a 'legitimate' use
> for this extension that required the use of an actual server name.
> 
> --Jens
> 
>> On Fri, Nov 1, 2019 at 6:37 AM Anthony Baker  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  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.
>>> 
>>> 
>>> 
>> 
>> 

Re: Special certificates for multisite

[Ju@N]

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  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  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

Re: Special certificates for multisite

[Jens Deppe]

I think it sounds pretty reasonable. Given that the only change to Geode
would be the suggested update to the ClientHello and we shouldn't need to
make any additional changes in order to leverage the functionality.
Presumably the custom Provider would need to be installed by the user and
configured for use in the JDK's java.security file.

The only downside would be if someone ever came up with a 'legitimate' use
for this extension that required the use of an actual server name.

--Jens

On Fri, Nov 1, 2019 at 6:37 AM Anthony Baker  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  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.
> >
> >
> >
>
>

Re: Special certificates for multisite

[Anthony Baker]

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  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 
> 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.
> 
> 
> 

Special certificates for multisite

[Mario Ivanac]

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 
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.