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