Good question. We can allow a user to use current properties ssl-protocols
and ssl-ciphers even when he wants to use the default security provider.
Here would be a sequence of steps user can to answer:
1) Decide whether you want SSL?
2) Great. Do you want to use
2.a) default ssl context? or
2.b) configure ssl context with specific trust and key store types,
locations, passwords.
3) In any case (2.a or 2.b) you have an option to restrict SSL protocols
and ciphers.
On Mon, Aug 13, 2018 at 8:38 AM Jens Deppe <jde...@pivotal.io> wrote:
> How does this work if the user wants to use the Trust/KeyStoreManager from
> the default security provider but still override other SSL properties such
> as ciphers or protocols?
>
> --Jens
>
> On Mon, Aug 13, 2018 at 8:32 AM Sai Boorlagadda <sai.boorlaga...@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.boorlaga...@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 <jil...@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 <aba...@pivotal.io>
> > wrote:
> > >>
> > >>>
> > >>>
> > >>> > On Aug 9, 2018, at 10:05 AM, Jacob Barrett <jbarr...@pivotal.io>
> > >>> wrote:
> > >>> >
> > >>> >
> > >>> >
> > >>> > On Aug 9, 2018, at 9:42 AM, Anthony Baker <aba...@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
> > >>
> > >
> >
>
