You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Dan Smith <ds...@pivotal.io> on 2020/03/16 22:33:06 UTC

[DISCUSS] Client side configuration for a SNI proxy

Hi all,

A new RFC is up for this feature
https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy.


Please review and comment by this Friday, 3/20/2020.

This hopefully addresses some of the concerns with the previous RFC for
this feature. The new proposal is for a more general SocketFactory property
that users can implement, along the lines of what Jake and Owen suggested.

-Dan

Re: [DISCUSS] Client side configuration for a SNI proxy

Posted by Jacob Barrett <jb...@pivotal.io>.
+1

> On Mar 18, 2020, at 4:13 PM, Dan Smith <ds...@pivotal.io> wrote:
> 
> One addendum to this proposal:
> 
> This proposed method of configuring a SNI proxy server requires that the
> client sends the SNI hostname as part of the TLS handshake. In the previous
> proposal we suggested it would only be sent if a SNI Proxy is configured.
> Now we propose that a geode client will *always* send the SNI hostname when
> it initiates a TLS connection to a locator or server.
> 
> This will help us implement the SniSocketFactory. It may also help with
> other use cases such as presenting different SSL certificates for different
> hostnames, which is the original reason this SNI hostname is part of TLS.
> The SSLParameterExtension will still take precedence, so I think this
> should not break the original use case for SSLParameterExtension [1]
> 
> -Dan
> 
> [1]
> https://lists.apache.org/thread.html/0e08a5d0a480115ace6412e16ad45023adf0c29406ec2095a4d19d30%40%3Cdev.geode.apache.org%3E
> 
> On Mon, Mar 16, 2020 at 3:33 PM Dan Smith <ds...@pivotal.io> wrote:
> 
>> Hi all,
>> 
>> A new RFC is up for this feature
>> https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy.
>> 
>> 
>> Please review and comment by this Friday, 3/20/2020.
>> 
>> This hopefully addresses some of the concerns with the previous RFC for
>> this feature. The new proposal is for a more general SocketFactory property
>> that users can implement, along the lines of what Jake and Owen suggested.
>> 
>> -Dan
>>

Re: [DISCUSS] Client side configuration for a SNI proxy

Posted by Bruce Schuchardt <bs...@pivotal.io>.
+1

On 3/18/20, 4:13 PM, "Dan Smith" <ds...@pivotal.io> wrote:

    One addendum to this proposal:
    
    This proposed method of configuring a SNI proxy server requires that the
    client sends the SNI hostname as part of the TLS handshake. In the previous
    proposal we suggested it would only be sent if a SNI Proxy is configured.
    Now we propose that a geode client will *always* send the SNI hostname when
    it initiates a TLS connection to a locator or server.
    
    This will help us implement the SniSocketFactory. It may also help with
    other use cases such as presenting different SSL certificates for different
    hostnames, which is the original reason this SNI hostname is part of TLS.
    The SSLParameterExtension will still take precedence, so I think this
    should not break the original use case for SSLParameterExtension [1]
    
    -Dan
    
    [1]
    https://lists.apache.org/thread.html/0e08a5d0a480115ace6412e16ad45023adf0c29406ec2095a4d19d30%40%3Cdev.geode.apache.org%3E
    
    On Mon, Mar 16, 2020 at 3:33 PM Dan Smith <ds...@pivotal.io> wrote:
    
    > Hi all,
    >
    > A new RFC is up for this feature
    > https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy.
    >
    >
    > Please review and comment by this Friday, 3/20/2020.
    >
    > This hopefully addresses some of the concerns with the previous RFC for
    > this feature. The new proposal is for a more general SocketFactory property
    > that users can implement, along the lines of what Jake and Owen suggested.
    >
    > -Dan
    >

Re: [DISCUSS] Client side configuration for a SNI proxy

Posted by Dan Smith <ds...@pivotal.io>.
One addendum to this proposal:

This proposed method of configuring a SNI proxy server requires that the
client sends the SNI hostname as part of the TLS handshake. In the previous
proposal we suggested it would only be sent if a SNI Proxy is configured.
Now we propose that a geode client will *always* send the SNI hostname when
it initiates a TLS connection to a locator or server.

This will help us implement the SniSocketFactory. It may also help with
other use cases such as presenting different SSL certificates for different
hostnames, which is the original reason this SNI hostname is part of TLS.
The SSLParameterExtension will still take precedence, so I think this
should not break the original use case for SSLParameterExtension [1]

-Dan

[1]
https://lists.apache.org/thread.html/0e08a5d0a480115ace6412e16ad45023adf0c29406ec2095a4d19d30%40%3Cdev.geode.apache.org%3E

On Mon, Mar 16, 2020 at 3:33 PM Dan Smith <ds...@pivotal.io> wrote:

> Hi all,
>
> A new RFC is up for this feature
> https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy.
>
>
> Please review and comment by this Friday, 3/20/2020.
>
> This hopefully addresses some of the concerns with the previous RFC for
> this feature. The new proposal is for a more general SocketFactory property
> that users can implement, along the lines of what Jake and Owen suggested.
>
> -Dan
>

Re: [DISCUSS] Client side configuration for a SNI proxy

Posted by Dan Smith <ds...@pivotal.io>.
Hi all,

It looks like we have consensus to go forward with this proposal. I've
moved it to the "In Development" state. Thanks all for your comments on
this and the previous RFC for this feature.

-Dan

On Thu, Mar 19, 2020 at 10:35 AM Jason Huynh <jh...@pivotal.io> wrote:

> +1
>
> On Thu, Mar 19, 2020 at 7:27 AM Joris Melchior <jm...@pivotal.io>
> wrote:
>
> > +1
> >
> > On Mon, Mar 16, 2020 at 6:33 PM Dan Smith <ds...@pivotal.io> wrote:
> >
> > > Hi all,
> > >
> > > A new RFC is up for this feature
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy
> > > .
> > >
> > >
> > > Please review and comment by this Friday, 3/20/2020.
> > >
> > > This hopefully addresses some of the concerns with the previous RFC for
> > > this feature. The new proposal is for a more general SocketFactory
> > property
> > > that users can implement, along the lines of what Jake and Owen
> > suggested.
> > >
> > > -Dan
> > >
> >
> >
> > --
> > *Joris Melchior *
> > CF Engineering
> > Pivotal Toronto
> > 416 877 5427
> >
> > “Programs must be written for people to read, and only incidentally for
> > machines to execute.” – *Hal Abelson*
> > <https://en.wikipedia.org/wiki/Hal_Abelson>
> >
>

Re: [DISCUSS] Client side configuration for a SNI proxy

Posted by Jason Huynh <jh...@pivotal.io>.
+1

On Thu, Mar 19, 2020 at 7:27 AM Joris Melchior <jm...@pivotal.io> wrote:

> +1
>
> On Mon, Mar 16, 2020 at 6:33 PM Dan Smith <ds...@pivotal.io> wrote:
>
> > Hi all,
> >
> > A new RFC is up for this feature
> >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy
> > .
> >
> >
> > Please review and comment by this Friday, 3/20/2020.
> >
> > This hopefully addresses some of the concerns with the previous RFC for
> > this feature. The new proposal is for a more general SocketFactory
> property
> > that users can implement, along the lines of what Jake and Owen
> suggested.
> >
> > -Dan
> >
>
>
> --
> *Joris Melchior *
> CF Engineering
> Pivotal Toronto
> 416 877 5427
>
> “Programs must be written for people to read, and only incidentally for
> machines to execute.” – *Hal Abelson*
> <https://en.wikipedia.org/wiki/Hal_Abelson>
>

Re: [DISCUSS] Client side configuration for a SNI proxy

Posted by Joris Melchior <jm...@pivotal.io>.
+1

On Mon, Mar 16, 2020 at 6:33 PM Dan Smith <ds...@pivotal.io> wrote:

> Hi all,
>
> A new RFC is up for this feature
>
> https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy
> .
>
>
> Please review and comment by this Friday, 3/20/2020.
>
> This hopefully addresses some of the concerns with the previous RFC for
> this feature. The new proposal is for a more general SocketFactory property
> that users can implement, along the lines of what Jake and Owen suggested.
>
> -Dan
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>