Is this an acceptable compatibility change? After seeing the feedback to always enable hostname validation. I settled on enabling hostname validation by default and let users choose to disable until their certificates are ready for endpoint validation. This allows users to migrate to GEODE 1.7.
Also added a log to warn users if they disable hostname validation that it will be mandatory to do validation. 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. > > Sai's other proposal for ssl-use-default-provider would let the user > configure the system to use the JDK's default provider ... which trusts > public CAs. > > I like Anthony's suggestion of always doing hostname verification. Until we > do, it seems like we will need this ssl-enable-endpoint-identification > property, so people can verify that their certificates will work in future > versions. If we are going to always do verification in the future maybe the > new ssl-use-default-provider property can do verification from the get-go? > > -Dan > > > > On Tue, Aug 14, 2018 at 8:59 AM, Jacob Barrett <jbarr...@pivotal.io> > wrote: > > > On Tue, Aug 14, 2018 at 7:47 AM Sai Boorlagadda < > > sai_boorlaga...@apache.org> > > wrote: > > > > > Geode currently does not implement hostname verification and is > probably > > > not required per TLS spec. But it can be supported on TLS as an > > additional > > > check. The new proposed[1] implementation to use the default SSL > context > > > could cause certain man-in-the-middle attacks possible if there is no > > > hostname verification. > > > > > > The current SSL implementation is also susceptible to man-in-the-middle > as > > well. This proposal is really independent of those proposed changes. > > > > > > > This is a proposal to add a new boolean SSL property > > > `ssl-enable-endpoint-identification` which enables hostname > verification > > > for secure connections. > > > > > > Are you proposing that we ship a custom trust manager that verifies hosts > > on all TLS connections? I would rather shy away from yet another > confusing > > SSL property. Is there a proposed why for consumers to provide their own > > trust manager and host verification process? If so, I assume that is yet > > another property, can we merge those properties somehow? > > > > At this point with all theses system properties can we come up with a > > better way to configure SSL? > > > > -Jake > > >
