Are we implementing the identification algorithm ourself or using one provided by setting that algorithm property? If we are implementing our own or just setting the algorithm to HTTPS and don’t foresee us using the LDAPS then a Boolean is sufficient. There isn’t really a whole lot different between the two algorithms by scanning the RFCs. The HTTPS algorithm is a bit more defined and covers IP addresses. The LDAPS has language explicitly denying DNS resolution in the process. I can’t imagine why we would use the LDAPS algorithm.
> On Aug 17, 2018, at 8:11 AM, Sai Boorlagadda <sai.boorlaga...@gmail.com> > wrote: > > 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 >>> >>
