I like this suggestion. +1 -- Mike Stolz Principal Engineer, GemFire Product Lead Mobile: +1-631-835-4771 Download the GemFire book here. <https://content.pivotal.io/ebooks/scaling-data-services-with-pivotal-gemfire>
On Tue, Aug 14, 2018 at 1:00 PM, Anthony Baker <aba...@pivotal.io> wrote: > What if we require certs to have correct hostnames and automatically > perform hostname verification. No property required. The only counter > argument I can think of is that this change might require users to > regenerate certificates when upgrading. Perhaps we start by logging a > warning for N releases, then make HN verification a hard requirement. > > Anthony > > > > On 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 > >
