I agree that hostname verification is independent of supporting default
context and I like Dan's suggestion of making hostname validation is
enabled by default if the user wants to use default SSL context otherwise
can be enabled using 'ssl-enable-endpoint-identification'.
Here is what the behavior going forward:
1) Decide whether you want SSL? Enabled using 'ssl-enabled-components'
2) Great. Do you want to use
2.a) default ssl context? (using ssl-use-default-context)
2.b) configure ssl context with specific trust and key store types,
locations, passwords (using ssl-key* and ssl-trust*)
3) In any case (2.a or 2.b) you have an option to restrict SSL protocols
and ciphers (using ssl-protocols, ssl-ciphers)
4) In any case (2.a or 2.b) you have an option to enable mutual auth (using
ssl-require-auth)
For 2.a, hostname validation is enabled by default.
For 2.b, user has a choice to enable using
'ssl-enabled-endpoint-identification'. We default this to false with a
warning and make it true in 2.0
The only simplification I see is making 2.a a default behavior when SSL is
configured and user does not specify ssl-key* and ssl-trust* parameters.
But as this will break backward compatibility as we default
{user-home}/.keystore, so the need for 2.a.
Sai
On Wed, Aug 15, 2018 at 8:58 PM Jacob Barrett <jbarr...@pivotal.io> wrote:
> On Tue, Aug 14, 2018 at 10:22 AM Dan Smith <dsm...@pivotal.io> wrote:
>
> > >
> > > The current SSL implementation is also susceptible to man-in-the-middle
> > as
> > > well. This proposal is really independent of those proposed changes.
> > >
> >
> > The current SSL implementation is not susceptible to man-in-the-middle
> > attacks, unless someone configures their client to trust public CAs
> rather
> > than directly trusting their gemfire servers. If you are using a public
> CA
> > model of trust, then you need hostname verification.
>
>
> 1) Compromise any host, client or server, in the cluster.
> 2) Copy key and certificate.
> 3) Hide tracks.
> 4) Create rouge host using stolen key and certificate pair.
> - Lack or hostname validation means my host with an otherwise valid
> cert can join the cluster.
> 5) Profit.
>
> While strictly not a CA trust man-in-the-middle, it has the same effect. It
> is an attack vector that hostname verification thwarts that current
> implementation does not.
>
> -Jake
>
