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
>> >>>
>> >>
>>
>
