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
