geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jinmei Liao <jil...@pivotal.io>
Subject Re: Proposal to support custom java.security.Provider
Date Mon, 13 Aug 2018 15:48:09 GMT
Doing #2 an #3 alone would fix GEODE-5338, right? We don't really need this
new option.

On Mon, Aug 13, 2018 at 8:32 AM Sai Boorlagadda <sai.boorlagadda@gmail.com>
wrote:

> To make it clear about the different options:
>
> 1) if ssl-enabled-component & ssl-use-default-context is configured then
> use default SSL context.
> 2) if ssl-enabled-component & no other ssl-* properties are configured then
> configure SSL context by loading truststore and keystore from user home
> directory.
> 3) if ssl-enabled-component & ssl-* properties are configured then
> configure SSL context as configured by user.
>
> While #2 and #3 are existing behavior, #1 is implemented as part of current
> proposal for GEODE-5338.
>
> On Mon, Aug 13, 2018 at 8:25 AM Sai Boorlagadda <sai.boorlagadda@gmail.com
> >
> wrote:
>
> > I missed follow up emails on this thread, for some reason my email client
> > didn't show there were new messages on this thread. Like Jinmei said, a
> > user has to first enable SSL by configuring ssl-enable-component and then
> > chose between using default context or using specific
> > keystore/trustsore (existing implementation).
> >
> > Also, I am dropping the idea of making it a new default to use default
> SSL
> > context as it will break backward compatibility.
> >
> > On Thu, Aug 9, 2018 at 10:52 AM Jinmei Liao <jiliao@pivotal.io> wrote:
> >
> >> let me see if my understanding is correct: if ssl-enabled-component is
> >> none, then we would accept non-ssl connections, no ssl context will be
> >> used. if ssl-enabled-component is something other than "none", but we
> don't
> >> specify any other ssl-* configurations, then we use the default ssl
> context
> >> provided by JDK, any customization to the JDK's ssl context (either by
> >> installing a custom provider or keystore/truststore installed in jdk's
> >> path) will be used this way. But we do specify any other ssl-*
> >> configurations, then we use our usual way of loading the ssl context.
> >>
> >> On Thu, Aug 9, 2018 at 10:33 AM Anthony Baker <abaker@pivotal.io>
> wrote:
> >>
> >>>
> >>>
> >>> > On Aug 9, 2018, at 10:05 AM, Jacob Barrett <jbarrett@pivotal.io>
> >>> wrote:
> >>> >
> >>> >
> >>> >
> >>> > On Aug 9, 2018, at 9:42 AM, Anthony Baker <abaker@pivotal.io>
wrote:
> >>> >
> >>> >>>
> >>> >>>
> >>> >>> I would like to also get consensus on defaulting GEODE's behavior
> to
> >>> always
> >>> >>> use default SSL context instead of introducing a new parameter
> >>> >>> 'ssl-use-default-sslcontext'. If user's have specified any
existing
> >>> ssl-*
> >>> >>> props then the current implementation is exercised (ie to configure
> >>> the
> >>> >>> context as per provided properties).
> >>> >>>
> >>> >>
> >>> >> If geode is always configured to use the default SSL context, how
do
> >>> we know to when to accept SSL v non-SSL connections?
> >>> >>
> >>> >
> >>> > The enable ssl properties.
> >>> >
> >>>
> >>> Sorry I’m missing something.  If the only time we accept SSL
> connections
> >>> is when you enable geode ssl-* properties, what is the point of
> enabling
> >>> the default SSL context by default?
> >>>
> >>> Anthony
> >>>
> >>>
> >>
> >> --
> >> Cheers
> >>
> >> Jinmei
> >>
> >
>


-- 
Cheers

Jinmei

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