+1 for making it default and to warn users before making it a hard requirement.
On Tue, Aug 14, 2018 at 10:00 AM 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 > >
