Stick with the JDK implementation as it is compliant with the current RFC. Most
certs still have the CN set to the hostname for legacy clients but newer
clients use the SAN. It’s doubtful many CA’s still produce certs without a SAN
entry.
> On Aug 24, 2018, at 6:49 PM, Sai Boorlagadda <sai.boorlaga...@gmail.com>
> wrote:
>
> all,
>
> While testing I found that JDK's endpoint identification algorithm
> ('HTTPS')
> validates the server's hostname:
>
> 1) against 'subject alternative name' (SAN) when available
> 2) against 'common name' (CN) if SAN is absent
>
> I was a little concerned about #2, which is deprecated as per [1].
>
>> So where do you look in the certificate? According to RFC 6125,
>> hostname verification should be done against the certificate's
>> subjectAlternativeName's dNSName field. In some legacy
>> implementations, the check is done against the certificate's
>> commonName field, but commonName is deprecated and
>> has been deprecated for quite a while now.
>
> But it looks to me that JDK's implementation is aligned with RFC 6125[2],
> According to RFC, Client's can validate against CN as a last resort.
>
>> As noted, a client MUST NOT seek a match for a reference identifier
>> of CN-ID if the presented identifiers include a DNS-ID, SRV-ID,
>> URI-ID, or any application-specific identifier types supported by the
> client.
>
>> Therefore, if and only if the presented identifiers do not include a
>> DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types
>> supported by the client, then the client MAY as a last resort check
>> for a string whose form matches that of a fully qualified DNS domain
>> name in a Common Name field of the subject field (i.e., a CN-ID).
>
> So looking to see if anyone has an opinion about JDK's implementation.
> After reading[1], I felt like there is a need for implementing a custom
> validation algorithm but after re-reading the RFC I started to believe that
> JDK's implementation is okay.
>
> [1] https://tersesystems.com/blog/2014/03/23/fixing-hostname-verification/
> [2] https://tools.ietf.org/search/rfc6125#section-6.4.4
>
> On Mon, Aug 20, 2018 at 9:25 AM Sai Boorlagadda <sai.boorlaga...@gmail.com>
> wrote:
>
>> 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
>>>>>>
>>>>>
>>>
>>
