Re: [Proposal] SSL - hostname verification

Yes, I thought it was not an acceptable change and thanks for confirming it. We do want to enable host validation when user configures to use default context. So hostname validation will be enabled if `ssl-use-default-sslcontext=true` else if user provides keystore and truststore then hostname

Re: [Proposal] SSL - hostname verification

How would a rolling upgrade work if my certificates don’t pass hostname verification? Would it be: 1) Regenerate new certificates with correct SAN / CN information 2) Deploy the new certificates 3) Do a rolling restart 4) Do a rolling upgrade to geode 1.7 *I think* that w/o steps 1-3 my

Re: [Proposal] SSL - hostname verification

okay! If users choose to disable hostname validation, then the warning in the log says in future releases the ability to disable will be removed. On Thu, Aug 30, 2018 at 2:59 PM Anthony Baker wrote: > > > > Also added a log to warn users if they disable hostname validation that > it > > will >

Re: [Proposal] SSL - hostname verification

> > Also added a log to warn users if they disable hostname validation that it > will > be mandatory to do validation. What does this mean? Anthony

Re: [Proposal] SSL - hostname verification

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 >

Re: [Proposal] SSL - hostname verification

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

Re: [Proposal] SSL - hostname verification

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 wrote: > Are we

Re: [Proposal] SSL - hostname verification

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

Re: [Proposal] SSL - hostname verification

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

Re: [Proposal] SSL - hostname verification

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

Re: [Proposal] SSL - hostname verification

I agree that hostname verification is independent of supporting default context and I like Dan's suggestion of making hostname validation is enabled by default if the user wants to use default SSL context otherwise can be enabled using 'ssl-enable-endpoint-identification'. Here is what the

Re: [Proposal] SSL - hostname verification

On Tue, Aug 14, 2018 at 10:22 AM Dan Smith wrote: > > > > The current SSL implementation is also susceptible to man-in-the-middle > as > > well. This proposal is really independent of those proposed changes. > > > > The current SSL implementation is not susceptible to man-in-the-middle >

Re: [Proposal] SSL - hostname verification

Bruce, > To which SSL connections would this apply? All of them? When enabled, these validations affect any client connecting to ssl enabled component depending on `ssl-enabled-components`. Sai On Tue, Aug 14, 2018 at 11:26 AM Bruce Schuchardt wrote: > Hi Sai > > To which SSL connections

Re: [Proposal] SSL - hostname verification

Hi Sai To which SSL connections would this apply?  All of them? On 8/14/18 7:46 AM, Sai Boorlagadda 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]

Re: [Proposal] SSL - 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. > The current SSL implementation is not susceptible to man-in-the-middle attacks, unless someone configures their client to trust public CAs rather

Re: [Proposal] SSL - hostname verification

+1 for making it default and to warn users before making it a hard requirement. On Tue, Aug 14, 2018 at 10:00 AM Anthony Baker wrote: > What if we require certs to have correct hostnames and automatically > perform hostname verification. No property required. The only counter > argument I can

Re: [Proposal] SSL - 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 proposal is independent of the proposed changes to use default context. In both cases, the risk is similar if keys are compromised. But in the

Re: [Proposal] SSL - hostname verification

I like this suggestion. +1 -- Mike Stolz Principal Engineer, GemFire Product Lead Mobile: +1-631-835-4771 Download the GemFire book here. On Tue, Aug 14, 2018 at 1:00 PM, Anthony Baker wrote: > What if we require

Re: [Proposal] SSL - hostname verification

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

Re: [Proposal] SSL - hostname verification

On Tue, Aug 14, 2018 at 7:47 AM Sai Boorlagadda 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

[Proposal] SSL - hostname verification

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