We are using the default algorithm provided by JDK and the proposed parameter is made boolean as there is no foresee for using different algorithms. I have the PR#2346[1] for review.
[1] https://github.com/apache/geode/pull/2346 On Fri, Aug 17, 2018, 8:50 AM Jacob Barrett <jbarr...@pivotal.io> wrote: > 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 > >>> > >> >
