My biggest concern now is the name of the property to enable this. 'ssl-enabled-endpoint-identification' in no way suggests any kind of validation. The word identification implies to me that it will identify and maybe log endpoints. I would change that to validation or some other term that implies the actual action the system intends to make when enabled.
Secondly I find the order of the words confusing. Is it ssl that is being enabled or endpoint identification? I would suggest ‘ssl-hostname-validation-enabled’ or some variant of that. First off this reads like a natural English sentence, “is ssl host name validation enabled?” Secondly the action “host validation” implies an assertion is being made about the validity of the hosts name. -Jake > On 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 >
