Thanks, Jake for the feedback. The reason for endpoint-identification in the parameter name is to be aligned with JDK. So maybe making it as 'ssl-endpoint-identification-enabled' would have been less confusing. I also want to bring to notice that in JDK its a string property in SSLParameters.setEndpointIdentificationAlgorithm(String algorithm) - which I believe takes HTTPS or LDAPS.
Not sure if Geode has plans to support LDAPS, in which case I would rather change the proposal to have a string parameter. But for now I like your suggestion about making it read like "is ssl endpoint identification enabled?" Sai On Fri, Aug 17, 2018 at 6:38 AM Jacob Barrett <jbarr...@pivotal.io> wrote: > 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 > > >
