You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Mario Ivanac <ma...@est.tech> on 2019/11/19 11:26:45 UTC
Proposal of new config property "ssl-server-name-extension"
Hi geode dev,
as a part of solution for https://issues.apache.org/jira/browse/GEODE-7414
we would like to introduce new config property "ssl-server-name-extension".
This property will contain generic string, which will be added as Server Name Indication (SNI) parameter to Client Hello message.
Do you agree with this proposal?
Thanks,
Mario
Re: Odg: Odg: Proposal of new config property "ssl-server-name-extension"
Posted by Charlie Black <cb...@pivotal.io>.
Sorry - I had sent the e-mail to Mario directly. Also thanks for hanging
in there with me through this.
The ClientHello message is what is throwing me. As long as the SNI
behaves like the extension to the standard I am fine. Meaning if "openssl
s_client -connect server:port -servername servername.com" returns the right
stuff we are fine.
Note: I might not have all the options right in the openssl command, but
-servername enables SNI.
With that in mind I am + 1 on this.
Charlie
On Tue, Nov 19, 2019 at 12:00 PM Mario Ivanac <ma...@est.tech> wrote:
> Hi,
>
> as described before:
>
> This property will contain generic string, which will be added as Server
> Name Indication (SNI) parameter to ClientHello message.
> ClientHello message is part of SSL handshake.
>
> Mario
> ------------------------------
> *Šalje:* Charlie Black <cb...@pivotal.io>
> *Poslano:* 19. studenog 2019. 18:20
> *Prima:* Mario Ivanac <ma...@est.tech>
> *Kopija:* dev@geode.apache.org <de...@geode.apache.org>
> *Predmet:* Re: Odg: Proposal of new config property
> "ssl-server-name-extension"
>
> The SSL handshake is done *before* the Geode handshake. So additions
> to the Geode handshake protocol will not affect SSL connections since the
> secure socket connection has already been negotiated and the Geode
> handshake is encrypted.
>
> Charlie
>
> On Tue, Nov 19, 2019 at 9:06 AM Mario Ivanac <ma...@est.tech>
> wrote:
>
> Hi all,
>
> this proposal and ticket are result of mail discussion "Special
> certificates for multisite":
>
>
> https://lists.apache.org/thread.html/2418dd1b5f9ae812daa48a51a8d2eb252a3c861a890264f47da3a4d3@%3Cdev.geode.apache.org%3E
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apache.org_thread.html_2418dd1b5f9ae812daa48a51a8d2eb252a3c861a890264f47da3a4d3-40-253Cdev.geode.apache.org-253E&d=DwMF-g&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=TeO8Y4MHxN-HWthX0kIhmTbHjxbnon-82BZ-g9Q6TDI&m=GG4kW5SuTjSCV707Igt5WbMQyay_8vOtB9nH8cLBgAM&s=PjLj2CJYNHbQUiMKrd-FKMqwbuxVERJifxQWpM4HM8k&e=>
>
>
> BR,
> Mario
> ------------------------------
> *Šalje:* Charlie Black <cb...@pivotal.io>
> *Poslano:* 19. studenog 2019. 17:24
> *Prima:* dev@geode.apache.org <de...@geode.apache.org>
> *Predmet:* Re: Proposal of new config property "ssl-server-name-extension"
>
> I have read the e-mail and the ticket I am not sure how this field is going
> to be used. Maybe you can expand on the intent of this field.
>
> From the property "ssl-server-name-extension" it feels like we are
> intending to correlate with something presented in the SSL certificate.
> It would be great if that was explained plainly for the reader in more
> detail.
>
> For now I can only -1.
>
> Charlie
>
> On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac <ma...@est.tech>
> wrote:
>
> > Hi geode dev,
> >
> > as a part of solution for
> https://issues.apache.org/jira/browse/GEODE-7414
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_GEODE-2D7414&d=DwMF-g&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=TeO8Y4MHxN-HWthX0kIhmTbHjxbnon-82BZ-g9Q6TDI&m=GG4kW5SuTjSCV707Igt5WbMQyay_8vOtB9nH8cLBgAM&s=4h7HHiRlRX_Cw8mVGuVfzHgfUbKul07BjaV1CVE3_H8&e=>
> > we would like to introduce new config property
> "ssl-server-name-extension".
> >
> > This property will contain generic string, which will be added as Server
> > Name Indication (SNI) parameter to Client Hello message.
> >
> > Do you agree with this proposal?
> >
> > Thanks,
> > Mario
> >
>
>
> --
> Charlie Black | cblack@pivotal.io
>
>
>
> --
> Charlie Black | cblack@pivotal.io
>
--
Charlie Black | cblack@pivotal.io
Odg: Odg: Proposal of new config property "ssl-server-name-extension"
Posted by Mario Ivanac <ma...@est.tech>.
Hi,
as described before:
This property will contain generic string, which will be added as Server Name Indication (SNI) parameter to ClientHello message.
ClientHello message is part of SSL handshake.
Mario
________________________________
Šalje: Charlie Black <cb...@pivotal.io>
Poslano: 19. studenog 2019. 18:20
Prima: Mario Ivanac <ma...@est.tech>
Kopija: dev@geode.apache.org <de...@geode.apache.org>
Predmet: Re: Odg: Proposal of new config property "ssl-server-name-extension"
The SSL handshake is done before the Geode handshake. So additions to the Geode handshake protocol will not affect SSL connections since the secure socket connection has already been negotiated and the Geode handshake is encrypted.
Charlie
On Tue, Nov 19, 2019 at 9:06 AM Mario Ivanac <ma...@est.tech> wrote:
Hi all,
this proposal and ticket are result of mail discussion "Special certificates for multisite":
https://lists.apache.org/thread.html/2418dd1b5f9ae812daa48a51a8d2eb252a3c861a890264f47da3a4d3@%3Cdev.geode.apache.org%3E<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apache.org_thread.html_2418dd1b5f9ae812daa48a51a8d2eb252a3c861a890264f47da3a4d3-40-253Cdev.geode.apache.org-253E&d=DwMF-g&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=TeO8Y4MHxN-HWthX0kIhmTbHjxbnon-82BZ-g9Q6TDI&m=GG4kW5SuTjSCV707Igt5WbMQyay_8vOtB9nH8cLBgAM&s=PjLj2CJYNHbQUiMKrd-FKMqwbuxVERJifxQWpM4HM8k&e=>
BR,
Mario
________________________________
Šalje: Charlie Black <cb...@pivotal.io>>
Poslano: 19. studenog 2019. 17:24
Prima: dev@geode.apache.org<ma...@geode.apache.org> <de...@geode.apache.org>>
Predmet: Re: Proposal of new config property "ssl-server-name-extension"
I have read the e-mail and the ticket I am not sure how this field is going
to be used. Maybe you can expand on the intent of this field.
From the property "ssl-server-name-extension" it feels like we are
intending to correlate with something presented in the SSL certificate.
It would be great if that was explained plainly for the reader in more
detail.
For now I can only -1.
Charlie
On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac <ma...@est.tech> wrote:
> Hi geode dev,
>
> as a part of solution for https://issues.apache.org/jira/browse/GEODE-7414<https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_GEODE-2D7414&d=DwMF-g&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=TeO8Y4MHxN-HWthX0kIhmTbHjxbnon-82BZ-g9Q6TDI&m=GG4kW5SuTjSCV707Igt5WbMQyay_8vOtB9nH8cLBgAM&s=4h7HHiRlRX_Cw8mVGuVfzHgfUbKul07BjaV1CVE3_H8&e=>
> we would like to introduce new config property "ssl-server-name-extension".
>
> This property will contain generic string, which will be added as Server
> Name Indication (SNI) parameter to Client Hello message.
>
> Do you agree with this proposal?
>
> Thanks,
> Mario
>
--
Charlie Black | cblack@pivotal.io<ma...@pivotal.io>
--
Charlie Black | cblack@pivotal.io<ma...@pivotal.io>
Re: Odg: Proposal of new config property "ssl-server-name-extension"
Posted by Charlie Black <cb...@pivotal.io>.
The SSL handshake is done *before* the Geode handshake. So additions to
the Geode handshake protocol will not affect SSL connections since the
secure socket connection has already been negotiated and the Geode
handshake is encrypted.
Charlie
On Tue, Nov 19, 2019 at 9:06 AM Mario Ivanac <ma...@est.tech> wrote:
> Hi all,
>
> this proposal and ticket are result of mail discussion "Special
> certificates for multisite":
>
>
> https://lists.apache.org/thread.html/2418dd1b5f9ae812daa48a51a8d2eb252a3c861a890264f47da3a4d3@%3Cdev.geode.apache.org%3E
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apache.org_thread.html_2418dd1b5f9ae812daa48a51a8d2eb252a3c861a890264f47da3a4d3-40-253Cdev.geode.apache.org-253E&d=DwMF-g&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=TeO8Y4MHxN-HWthX0kIhmTbHjxbnon-82BZ-g9Q6TDI&m=GG4kW5SuTjSCV707Igt5WbMQyay_8vOtB9nH8cLBgAM&s=PjLj2CJYNHbQUiMKrd-FKMqwbuxVERJifxQWpM4HM8k&e=>
>
>
> BR,
> Mario
> ------------------------------
> *Šalje:* Charlie Black <cb...@pivotal.io>
> *Poslano:* 19. studenog 2019. 17:24
> *Prima:* dev@geode.apache.org <de...@geode.apache.org>
> *Predmet:* Re: Proposal of new config property "ssl-server-name-extension"
>
> I have read the e-mail and the ticket I am not sure how this field is going
> to be used. Maybe you can expand on the intent of this field.
>
> From the property "ssl-server-name-extension" it feels like we are
> intending to correlate with something presented in the SSL certificate.
> It would be great if that was explained plainly for the reader in more
> detail.
>
> For now I can only -1.
>
> Charlie
>
> On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac <ma...@est.tech>
> wrote:
>
> > Hi geode dev,
> >
> > as a part of solution for
> https://issues.apache.org/jira/browse/GEODE-7414
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_GEODE-2D7414&d=DwMF-g&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=TeO8Y4MHxN-HWthX0kIhmTbHjxbnon-82BZ-g9Q6TDI&m=GG4kW5SuTjSCV707Igt5WbMQyay_8vOtB9nH8cLBgAM&s=4h7HHiRlRX_Cw8mVGuVfzHgfUbKul07BjaV1CVE3_H8&e=>
> > we would like to introduce new config property
> "ssl-server-name-extension".
> >
> > This property will contain generic string, which will be added as Server
> > Name Indication (SNI) parameter to Client Hello message.
> >
> > Do you agree with this proposal?
> >
> > Thanks,
> > Mario
> >
>
>
> --
> Charlie Black | cblack@pivotal.io
>
--
Charlie Black | cblack@pivotal.io
Odg: Proposal of new config property "ssl-server-name-extension"
Posted by Mario Ivanac <ma...@est.tech>.
Hi all,
this proposal and ticket are result of mail discussion "Special certificates for multisite":
https://lists.apache.org/thread.html/2418dd1b5f9ae812daa48a51a8d2eb252a3c861a890264f47da3a4d3@%3Cdev.geode.apache.org%3E
BR,
Mario
________________________________
Šalje: Charlie Black <cb...@pivotal.io>
Poslano: 19. studenog 2019. 17:24
Prima: dev@geode.apache.org <de...@geode.apache.org>
Predmet: Re: Proposal of new config property "ssl-server-name-extension"
I have read the e-mail and the ticket I am not sure how this field is going
to be used. Maybe you can expand on the intent of this field.
From the property "ssl-server-name-extension" it feels like we are
intending to correlate with something presented in the SSL certificate.
It would be great if that was explained plainly for the reader in more
detail.
For now I can only -1.
Charlie
On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac <ma...@est.tech> wrote:
> Hi geode dev,
>
> as a part of solution for https://issues.apache.org/jira/browse/GEODE-7414
> we would like to introduce new config property "ssl-server-name-extension".
>
> This property will contain generic string, which will be added as Server
> Name Indication (SNI) parameter to Client Hello message.
>
> Do you agree with this proposal?
>
> Thanks,
> Mario
>
--
Charlie Black | cblack@pivotal.io
Odg: Proposal of new config property "ssl-server-name-extension"
Posted by Mario Ivanac <ma...@est.tech>.
Hi,
all connections will use ssl-server-name-extension as part of Client Hello.
BR,
Mario
________________________________
Šalje: Dan Smith <ds...@pivotal.io>
Poslano: 19. studenog 2019. 22:17
Prima: dev@geode.apache.org <de...@geode.apache.org>
Predmet: Re: Proposal of new config property "ssl-server-name-extension"
Can you clarify which connections will use this ssl-server-name-extension
as part of the Client Hello? client to locator, client to server, server to
server, WAN site to WAN site, ... all of the above?
I'm fine with adding the new property.
At some point, I think we need to think about making it easier to plug in
custom logic to control the entire socket creation and TLS handshake. I
think technically you can take over the whole process if you set the
ssl-use-default-context property and then configure the default SSLContext
for your entire process, but that is not ideal.
-Dan
On Tue, Nov 19, 2019 at 8:24 AM Charlie Black <cb...@pivotal.io> wrote:
> I have read the e-mail and the ticket I am not sure how this field is going
> to be used. Maybe you can expand on the intent of this field.
>
> From the property "ssl-server-name-extension" it feels like we are
> intending to correlate with something presented in the SSL certificate.
> It would be great if that was explained plainly for the reader in more
> detail.
>
> For now I can only -1.
>
> Charlie
>
> On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac <ma...@est.tech>
> wrote:
>
> > Hi geode dev,
> >
> > as a part of solution for
> https://issues.apache.org/jira/browse/GEODE-7414
> > we would like to introduce new config property
> "ssl-server-name-extension".
> >
> > This property will contain generic string, which will be added as Server
> > Name Indication (SNI) parameter to Client Hello message.
> >
> > Do you agree with this proposal?
> >
> > Thanks,
> > Mario
> >
>
>
> --
> Charlie Black | cblack@pivotal.io
>
Odg: Proposal of new config property "ssl-server-name-extension"
Posted by Mario Ivanac <ma...@est.tech>.
Hi,
regarding your questions:
>>Mario, are there any limitations that should be understood about the types
of certificates used or how they're generated?<<
There is no limitations.
>>Do you have the freedom to use certificate chaining and have the root CA in each component's
truststore?<<
Yes
BR,
Mario
________________________________
Šalje: Ivan Godwin <ig...@pivotal.io>
Poslano: 21. studenog 2019. 4:29
Prima: dev@geode.apache.org <de...@geode.apache.org>
Predmet: Re: Proposal of new config property "ssl-server-name-extension"
Thank you for the reference to the other thread, Jens. I hope my questions
aren't too late in the process.
Mario, are there any limitations that should be understood about the types
of certificates used or how they're generated? Do you have the freedom to
use certificate chaining and have the root CA in each component's
truststore? Dan's concern of a future, valid use case resonates quite a bit
with me.
Ivan
On Wed, Nov 20, 2019, 18:43 Jens Deppe <jd...@pivotal.io> wrote:
> This thread contains more background on the reasons for this proposal:
>
> https://lists.apache.org/thread.html/2418dd1b5f9ae812daa48a51a8d2eb252a3c861a890264f47da3a4d3@%3Cdev.geode.apache.org%3E
>
> On Wed, Nov 20, 2019 at 10:46 AM Ivan Godwin <ig...@pivotal.io> wrote:
>
> > I've reviewed the PR and I believe I understand the use case, but I feel
> a
> > bit uncomfortable with the misuse of SNI. As I understand it, and as it
> has
> > been already mentioned, SNI is used to determine which SSL certificate
> > should be presented to a client.
> >
> > I think that CLIENT_HELLO_EXTENSION should *not* be associated with SSL,
> > and that a new client property should be used instead. That is, a
> different
> > property, unrelated to SSL, should be used to set what will be verified
> > against CLIENT_HELLO_EXTENSION.
> >
> > On Tue, Nov 19, 2019 at 4:43 PM Jens Deppe <jd...@pivotal.io> wrote:
> >
> > > I'd like to add my comment from the original PR here again:
> > >
> > >
> > > Although I support the particular use case, I would prefer the
> > > implementation being a bit more abstracted. Specifically, if we
> provided
> > an
> > > extension point which would allow modification of SSLParameters then we
> > > wouldn't be coupling to a particular use case. So I'm thinking that the
> > > user would define (via say a ssl-parameter-extension parameter) a class
> > > that takes in a SSLParameter and perhaps SSLConfig and whatever else
> for
> > > this use-case and does what it needs. The user class would need to
> > > implement an interface something like this:
> > >
> > > public interface SSLParameterExtension {
> > > SSLParameter modify(SSLParameter, SSLConfig);
> > > }
> > >
> > > I would imagine seeing the user implementation of this being attached
> to
> > > SSLConfig.
> > >
> > >
> > > (https://github.com/apache/geode/pull/4310)
> > >
> > > I don't mind (mis)using the Server Name field to convey some other
> > > information, but since it's possible to abstract the specific nature
> and
> > > application of that information, I think we should do so. Anyone else
> who
> > > looks at the code is going to wonder what the use is especially if the
> > > consumer of that particular piece of info is going to be provided via
> an
> > > external SSLEngine implementation.
> > >
> > > --Jens
> > >
> > > On Tue, Nov 19, 2019 at 1:18 PM Dan Smith <ds...@pivotal.io> wrote:
> > >
> > > > Can you clarify which connections will use this
> > ssl-server-name-extension
> > > > as part of the Client Hello? client to locator, client to server,
> > server
> > > to
> > > > server, WAN site to WAN site, ... all of the above?
> > > >
> > > > I'm fine with adding the new property.
> > > >
> > > > At some point, I think we need to think about making it easier to
> plug
> > in
> > > > custom logic to control the entire socket creation and TLS
> handshake. I
> > > > think technically you can take over the whole process if you set the
> > > > ssl-use-default-context property and then configure the default
> > > SSLContext
> > > > for your entire process, but that is not ideal.
> > > >
> > > > -Dan
> > > >
> > > > On Tue, Nov 19, 2019 at 8:24 AM Charlie Black <cb...@pivotal.io>
> > wrote:
> > > >
> > > > > I have read the e-mail and the ticket I am not sure how this field
> is
> > > > going
> > > > > to be used. Maybe you can expand on the intent of this field.
> > > > >
> > > > > From the property "ssl-server-name-extension" it feels like we are
> > > > > intending to correlate with something presented in the SSL
> > certificate.
> > > > > It would be great if that was explained plainly for the reader in
> > more
> > > > > detail.
> > > > >
> > > > > For now I can only -1.
> > > > >
> > > > > Charlie
> > > > >
> > > > > On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac <mario.ivanac@est.tech
> >
> > > > > wrote:
> > > > >
> > > > > > Hi geode dev,
> > > > > >
> > > > > > as a part of solution for
> > > > > https://issues.apache.org/jira/browse/GEODE-7414
> > > > > > we would like to introduce new config property
> > > > > "ssl-server-name-extension".
> > > > > >
> > > > > > This property will contain generic string, which will be added as
> > > > Server
> > > > > > Name Indication (SNI) parameter to Client Hello message.
> > > > > >
> > > > > > Do you agree with this proposal?
> > > > > >
> > > > > > Thanks,
> > > > > > Mario
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Charlie Black | cblack@pivotal.io
> > > > >
> > > >
> > >
> >
>
Re: Proposal of new config property "ssl-server-name-extension"
Posted by Ivan Godwin <ig...@pivotal.io>.
Thank you for the reference to the other thread, Jens. I hope my questions
aren't too late in the process.
Mario, are there any limitations that should be understood about the types
of certificates used or how they're generated? Do you have the freedom to
use certificate chaining and have the root CA in each component's
truststore? Dan's concern of a future, valid use case resonates quite a bit
with me.
Ivan
On Wed, Nov 20, 2019, 18:43 Jens Deppe <jd...@pivotal.io> wrote:
> This thread contains more background on the reasons for this proposal:
>
> https://lists.apache.org/thread.html/2418dd1b5f9ae812daa48a51a8d2eb252a3c861a890264f47da3a4d3@%3Cdev.geode.apache.org%3E
>
> On Wed, Nov 20, 2019 at 10:46 AM Ivan Godwin <ig...@pivotal.io> wrote:
>
> > I've reviewed the PR and I believe I understand the use case, but I feel
> a
> > bit uncomfortable with the misuse of SNI. As I understand it, and as it
> has
> > been already mentioned, SNI is used to determine which SSL certificate
> > should be presented to a client.
> >
> > I think that CLIENT_HELLO_EXTENSION should *not* be associated with SSL,
> > and that a new client property should be used instead. That is, a
> different
> > property, unrelated to SSL, should be used to set what will be verified
> > against CLIENT_HELLO_EXTENSION.
> >
> > On Tue, Nov 19, 2019 at 4:43 PM Jens Deppe <jd...@pivotal.io> wrote:
> >
> > > I'd like to add my comment from the original PR here again:
> > >
> > >
> > > Although I support the particular use case, I would prefer the
> > > implementation being a bit more abstracted. Specifically, if we
> provided
> > an
> > > extension point which would allow modification of SSLParameters then we
> > > wouldn't be coupling to a particular use case. So I'm thinking that the
> > > user would define (via say a ssl-parameter-extension parameter) a class
> > > that takes in a SSLParameter and perhaps SSLConfig and whatever else
> for
> > > this use-case and does what it needs. The user class would need to
> > > implement an interface something like this:
> > >
> > > public interface SSLParameterExtension {
> > > SSLParameter modify(SSLParameter, SSLConfig);
> > > }
> > >
> > > I would imagine seeing the user implementation of this being attached
> to
> > > SSLConfig.
> > >
> > >
> > > (https://github.com/apache/geode/pull/4310)
> > >
> > > I don't mind (mis)using the Server Name field to convey some other
> > > information, but since it's possible to abstract the specific nature
> and
> > > application of that information, I think we should do so. Anyone else
> who
> > > looks at the code is going to wonder what the use is especially if the
> > > consumer of that particular piece of info is going to be provided via
> an
> > > external SSLEngine implementation.
> > >
> > > --Jens
> > >
> > > On Tue, Nov 19, 2019 at 1:18 PM Dan Smith <ds...@pivotal.io> wrote:
> > >
> > > > Can you clarify which connections will use this
> > ssl-server-name-extension
> > > > as part of the Client Hello? client to locator, client to server,
> > server
> > > to
> > > > server, WAN site to WAN site, ... all of the above?
> > > >
> > > > I'm fine with adding the new property.
> > > >
> > > > At some point, I think we need to think about making it easier to
> plug
> > in
> > > > custom logic to control the entire socket creation and TLS
> handshake. I
> > > > think technically you can take over the whole process if you set the
> > > > ssl-use-default-context property and then configure the default
> > > SSLContext
> > > > for your entire process, but that is not ideal.
> > > >
> > > > -Dan
> > > >
> > > > On Tue, Nov 19, 2019 at 8:24 AM Charlie Black <cb...@pivotal.io>
> > wrote:
> > > >
> > > > > I have read the e-mail and the ticket I am not sure how this field
> is
> > > > going
> > > > > to be used. Maybe you can expand on the intent of this field.
> > > > >
> > > > > From the property "ssl-server-name-extension" it feels like we are
> > > > > intending to correlate with something presented in the SSL
> > certificate.
> > > > > It would be great if that was explained plainly for the reader in
> > more
> > > > > detail.
> > > > >
> > > > > For now I can only -1.
> > > > >
> > > > > Charlie
> > > > >
> > > > > On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac <mario.ivanac@est.tech
> >
> > > > > wrote:
> > > > >
> > > > > > Hi geode dev,
> > > > > >
> > > > > > as a part of solution for
> > > > > https://issues.apache.org/jira/browse/GEODE-7414
> > > > > > we would like to introduce new config property
> > > > > "ssl-server-name-extension".
> > > > > >
> > > > > > This property will contain generic string, which will be added as
> > > > Server
> > > > > > Name Indication (SNI) parameter to Client Hello message.
> > > > > >
> > > > > > Do you agree with this proposal?
> > > > > >
> > > > > > Thanks,
> > > > > > Mario
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Charlie Black | cblack@pivotal.io
> > > > >
> > > >
> > >
> >
>
Re: Proposal of new config property "ssl-server-name-extension"
Posted by Jens Deppe <jd...@pivotal.io>.
This thread contains more background on the reasons for this proposal:
https://lists.apache.org/thread.html/2418dd1b5f9ae812daa48a51a8d2eb252a3c861a890264f47da3a4d3@%3Cdev.geode.apache.org%3E
On Wed, Nov 20, 2019 at 10:46 AM Ivan Godwin <ig...@pivotal.io> wrote:
> I've reviewed the PR and I believe I understand the use case, but I feel a
> bit uncomfortable with the misuse of SNI. As I understand it, and as it has
> been already mentioned, SNI is used to determine which SSL certificate
> should be presented to a client.
>
> I think that CLIENT_HELLO_EXTENSION should *not* be associated with SSL,
> and that a new client property should be used instead. That is, a different
> property, unrelated to SSL, should be used to set what will be verified
> against CLIENT_HELLO_EXTENSION.
>
> On Tue, Nov 19, 2019 at 4:43 PM Jens Deppe <jd...@pivotal.io> wrote:
>
> > I'd like to add my comment from the original PR here again:
> >
> >
> > Although I support the particular use case, I would prefer the
> > implementation being a bit more abstracted. Specifically, if we provided
> an
> > extension point which would allow modification of SSLParameters then we
> > wouldn't be coupling to a particular use case. So I'm thinking that the
> > user would define (via say a ssl-parameter-extension parameter) a class
> > that takes in a SSLParameter and perhaps SSLConfig and whatever else for
> > this use-case and does what it needs. The user class would need to
> > implement an interface something like this:
> >
> > public interface SSLParameterExtension {
> > SSLParameter modify(SSLParameter, SSLConfig);
> > }
> >
> > I would imagine seeing the user implementation of this being attached to
> > SSLConfig.
> >
> >
> > (https://github.com/apache/geode/pull/4310)
> >
> > I don't mind (mis)using the Server Name field to convey some other
> > information, but since it's possible to abstract the specific nature and
> > application of that information, I think we should do so. Anyone else who
> > looks at the code is going to wonder what the use is especially if the
> > consumer of that particular piece of info is going to be provided via an
> > external SSLEngine implementation.
> >
> > --Jens
> >
> > On Tue, Nov 19, 2019 at 1:18 PM Dan Smith <ds...@pivotal.io> wrote:
> >
> > > Can you clarify which connections will use this
> ssl-server-name-extension
> > > as part of the Client Hello? client to locator, client to server,
> server
> > to
> > > server, WAN site to WAN site, ... all of the above?
> > >
> > > I'm fine with adding the new property.
> > >
> > > At some point, I think we need to think about making it easier to plug
> in
> > > custom logic to control the entire socket creation and TLS handshake. I
> > > think technically you can take over the whole process if you set the
> > > ssl-use-default-context property and then configure the default
> > SSLContext
> > > for your entire process, but that is not ideal.
> > >
> > > -Dan
> > >
> > > On Tue, Nov 19, 2019 at 8:24 AM Charlie Black <cb...@pivotal.io>
> wrote:
> > >
> > > > I have read the e-mail and the ticket I am not sure how this field is
> > > going
> > > > to be used. Maybe you can expand on the intent of this field.
> > > >
> > > > From the property "ssl-server-name-extension" it feels like we are
> > > > intending to correlate with something presented in the SSL
> certificate.
> > > > It would be great if that was explained plainly for the reader in
> more
> > > > detail.
> > > >
> > > > For now I can only -1.
> > > >
> > > > Charlie
> > > >
> > > > On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac <ma...@est.tech>
> > > > wrote:
> > > >
> > > > > Hi geode dev,
> > > > >
> > > > > as a part of solution for
> > > > https://issues.apache.org/jira/browse/GEODE-7414
> > > > > we would like to introduce new config property
> > > > "ssl-server-name-extension".
> > > > >
> > > > > This property will contain generic string, which will be added as
> > > Server
> > > > > Name Indication (SNI) parameter to Client Hello message.
> > > > >
> > > > > Do you agree with this proposal?
> > > > >
> > > > > Thanks,
> > > > > Mario
> > > > >
> > > >
> > > >
> > > > --
> > > > Charlie Black | cblack@pivotal.io
> > > >
> > >
> >
>
Re: Proposal of new config property "ssl-server-name-extension"
Posted by Ivan Godwin <ig...@pivotal.io>.
I've reviewed the PR and I believe I understand the use case, but I feel a
bit uncomfortable with the misuse of SNI. As I understand it, and as it has
been already mentioned, SNI is used to determine which SSL certificate
should be presented to a client.
I think that CLIENT_HELLO_EXTENSION should *not* be associated with SSL,
and that a new client property should be used instead. That is, a different
property, unrelated to SSL, should be used to set what will be verified
against CLIENT_HELLO_EXTENSION.
On Tue, Nov 19, 2019 at 4:43 PM Jens Deppe <jd...@pivotal.io> wrote:
> I'd like to add my comment from the original PR here again:
>
>
> Although I support the particular use case, I would prefer the
> implementation being a bit more abstracted. Specifically, if we provided an
> extension point which would allow modification of SSLParameters then we
> wouldn't be coupling to a particular use case. So I'm thinking that the
> user would define (via say a ssl-parameter-extension parameter) a class
> that takes in a SSLParameter and perhaps SSLConfig and whatever else for
> this use-case and does what it needs. The user class would need to
> implement an interface something like this:
>
> public interface SSLParameterExtension {
> SSLParameter modify(SSLParameter, SSLConfig);
> }
>
> I would imagine seeing the user implementation of this being attached to
> SSLConfig.
>
>
> (https://github.com/apache/geode/pull/4310)
>
> I don't mind (mis)using the Server Name field to convey some other
> information, but since it's possible to abstract the specific nature and
> application of that information, I think we should do so. Anyone else who
> looks at the code is going to wonder what the use is especially if the
> consumer of that particular piece of info is going to be provided via an
> external SSLEngine implementation.
>
> --Jens
>
> On Tue, Nov 19, 2019 at 1:18 PM Dan Smith <ds...@pivotal.io> wrote:
>
> > Can you clarify which connections will use this ssl-server-name-extension
> > as part of the Client Hello? client to locator, client to server, server
> to
> > server, WAN site to WAN site, ... all of the above?
> >
> > I'm fine with adding the new property.
> >
> > At some point, I think we need to think about making it easier to plug in
> > custom logic to control the entire socket creation and TLS handshake. I
> > think technically you can take over the whole process if you set the
> > ssl-use-default-context property and then configure the default
> SSLContext
> > for your entire process, but that is not ideal.
> >
> > -Dan
> >
> > On Tue, Nov 19, 2019 at 8:24 AM Charlie Black <cb...@pivotal.io> wrote:
> >
> > > I have read the e-mail and the ticket I am not sure how this field is
> > going
> > > to be used. Maybe you can expand on the intent of this field.
> > >
> > > From the property "ssl-server-name-extension" it feels like we are
> > > intending to correlate with something presented in the SSL certificate.
> > > It would be great if that was explained plainly for the reader in more
> > > detail.
> > >
> > > For now I can only -1.
> > >
> > > Charlie
> > >
> > > On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac <ma...@est.tech>
> > > wrote:
> > >
> > > > Hi geode dev,
> > > >
> > > > as a part of solution for
> > > https://issues.apache.org/jira/browse/GEODE-7414
> > > > we would like to introduce new config property
> > > "ssl-server-name-extension".
> > > >
> > > > This property will contain generic string, which will be added as
> > Server
> > > > Name Indication (SNI) parameter to Client Hello message.
> > > >
> > > > Do you agree with this proposal?
> > > >
> > > > Thanks,
> > > > Mario
> > > >
> > >
> > >
> > > --
> > > Charlie Black | cblack@pivotal.io
> > >
> >
>
Re: Proposal of new config property "ssl-server-name-extension"
Posted by Jens Deppe <jd...@pivotal.io>.
I'd like to add my comment from the original PR here again:
Although I support the particular use case, I would prefer the
implementation being a bit more abstracted. Specifically, if we provided an
extension point which would allow modification of SSLParameters then we
wouldn't be coupling to a particular use case. So I'm thinking that the
user would define (via say a ssl-parameter-extension parameter) a class
that takes in a SSLParameter and perhaps SSLConfig and whatever else for
this use-case and does what it needs. The user class would need to
implement an interface something like this:
public interface SSLParameterExtension {
SSLParameter modify(SSLParameter, SSLConfig);
}
I would imagine seeing the user implementation of this being attached to
SSLConfig.
(https://github.com/apache/geode/pull/4310)
I don't mind (mis)using the Server Name field to convey some other
information, but since it's possible to abstract the specific nature and
application of that information, I think we should do so. Anyone else who
looks at the code is going to wonder what the use is especially if the
consumer of that particular piece of info is going to be provided via an
external SSLEngine implementation.
--Jens
On Tue, Nov 19, 2019 at 1:18 PM Dan Smith <ds...@pivotal.io> wrote:
> Can you clarify which connections will use this ssl-server-name-extension
> as part of the Client Hello? client to locator, client to server, server to
> server, WAN site to WAN site, ... all of the above?
>
> I'm fine with adding the new property.
>
> At some point, I think we need to think about making it easier to plug in
> custom logic to control the entire socket creation and TLS handshake. I
> think technically you can take over the whole process if you set the
> ssl-use-default-context property and then configure the default SSLContext
> for your entire process, but that is not ideal.
>
> -Dan
>
> On Tue, Nov 19, 2019 at 8:24 AM Charlie Black <cb...@pivotal.io> wrote:
>
> > I have read the e-mail and the ticket I am not sure how this field is
> going
> > to be used. Maybe you can expand on the intent of this field.
> >
> > From the property "ssl-server-name-extension" it feels like we are
> > intending to correlate with something presented in the SSL certificate.
> > It would be great if that was explained plainly for the reader in more
> > detail.
> >
> > For now I can only -1.
> >
> > Charlie
> >
> > On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac <ma...@est.tech>
> > wrote:
> >
> > > Hi geode dev,
> > >
> > > as a part of solution for
> > https://issues.apache.org/jira/browse/GEODE-7414
> > > we would like to introduce new config property
> > "ssl-server-name-extension".
> > >
> > > This property will contain generic string, which will be added as
> Server
> > > Name Indication (SNI) parameter to Client Hello message.
> > >
> > > Do you agree with this proposal?
> > >
> > > Thanks,
> > > Mario
> > >
> >
> >
> > --
> > Charlie Black | cblack@pivotal.io
> >
>
Re: Proposal of new config property "ssl-server-name-extension"
Posted by Dan Smith <ds...@pivotal.io>.
Can you clarify which connections will use this ssl-server-name-extension
as part of the Client Hello? client to locator, client to server, server to
server, WAN site to WAN site, ... all of the above?
I'm fine with adding the new property.
At some point, I think we need to think about making it easier to plug in
custom logic to control the entire socket creation and TLS handshake. I
think technically you can take over the whole process if you set the
ssl-use-default-context property and then configure the default SSLContext
for your entire process, but that is not ideal.
-Dan
On Tue, Nov 19, 2019 at 8:24 AM Charlie Black <cb...@pivotal.io> wrote:
> I have read the e-mail and the ticket I am not sure how this field is going
> to be used. Maybe you can expand on the intent of this field.
>
> From the property "ssl-server-name-extension" it feels like we are
> intending to correlate with something presented in the SSL certificate.
> It would be great if that was explained plainly for the reader in more
> detail.
>
> For now I can only -1.
>
> Charlie
>
> On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac <ma...@est.tech>
> wrote:
>
> > Hi geode dev,
> >
> > as a part of solution for
> https://issues.apache.org/jira/browse/GEODE-7414
> > we would like to introduce new config property
> "ssl-server-name-extension".
> >
> > This property will contain generic string, which will be added as Server
> > Name Indication (SNI) parameter to Client Hello message.
> >
> > Do you agree with this proposal?
> >
> > Thanks,
> > Mario
> >
>
>
> --
> Charlie Black | cblack@pivotal.io
>
Re: Proposal of new config property "ssl-server-name-extension"
Posted by Charlie Black <cb...@pivotal.io>.
I have read the e-mail and the ticket I am not sure how this field is going
to be used. Maybe you can expand on the intent of this field.
From the property "ssl-server-name-extension" it feels like we are
intending to correlate with something presented in the SSL certificate.
It would be great if that was explained plainly for the reader in more
detail.
For now I can only -1.
Charlie
On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac <ma...@est.tech> wrote:
> Hi geode dev,
>
> as a part of solution for https://issues.apache.org/jira/browse/GEODE-7414
> we would like to introduce new config property "ssl-server-name-extension".
>
> This property will contain generic string, which will be added as Server
> Name Indication (SNI) parameter to Client Hello message.
>
> Do you agree with this proposal?
>
> Thanks,
> Mario
>
--
Charlie Black | cblack@pivotal.io
Odg: Odg: Proposal of new config property "ssl-server-name-extension"
Posted by Mario Ivanac <ma...@est.tech>.
Hi,
I agree with your proposal/question,
and implementation will follow it.
BR,
Mario
________________________________
Šalje: Jens Deppe <jd...@pivotal.io>
Poslano: 9. prosinca 2019. 15:55
Prima: dev@geode.apache.org <de...@geode.apache.org>
Predmet: Re: Odg: Proposal of new config property "ssl-server-name-extension"
Hi Mario,
I did have a question / suggestion about this proposal (possibly on a
different thread). Would you mind responding to that before proceeding
please. I'll just paste it in here too.
> Jens Deppe <jd...@pivotal.io>
> Tue, Nov 19, 4:42 PM
> to dev
> I'd like to add my comment from the original PR here again:
>
>
> Although I support the particular use case, I would prefer the
> implementation being a bit more abstracted. Specifically, if we provided an
> extension point which would allow modification of SSLParameters then we
> wouldn't be coupling to a particular use case. So I'm thinking that the
> user would define (via say a ssl-parameter-extension parameter) a class
> that takes in a SSLParameter and perhaps SSLConfig and whatever else for
> this use-case and does what it needs. The user class would need to
> implement an interface something like this:
>
> public interface SSLParameterExtension {
> SSLParameter modify(SSLParameter, SSLConfig);
> }
>
> I would imagine seeing the user implementation of this being attached to
> SSLConfig.
>
>
> (https://github.com/apache/geode/pull/4310)
>
> I don't mind (mis)using the Server Name field to convey some other
> information, but since it's possible to abstract the specific nature and
> application of that information, I think we should do so. Anyone else who
> looks at the code is going to wonder what the use is especially if the
> consumer of that particular piece of info is going to be provided via an
> external SSLEngine implementation.
>
>
Thanks!
--Jens
On Mon, Dec 9, 2019 at 2:37 AM Mario Ivanac <ma...@est.tech> wrote:
> Hi,
>
> Since this proposal is open for almost three weeks,
> and we have 2 plus one,
>
> We will continue with proposed solution.
>
> Regards,
> Mario
>
> ________________________________
> Šalje: Mario Ivanac <ma...@est.tech>
> Poslano: 19. studenog 2019. 12:26
> Prima: dev@geode.apache.org <de...@geode.apache.org>
> Predmet: Proposal of new config property "ssl-server-name-extension"
>
> Hi geode dev,
>
> as a part of solution for https://issues.apache.org/jira/browse/GEODE-7414
> we would like to introduce new config property "ssl-server-name-extension".
>
> This property will contain generic string, which will be added as Server
> Name Indication (SNI) parameter to Client Hello message.
>
> Do you agree with this proposal?
>
> Thanks,
> Mario
>
Re: Odg: Proposal of new config property "ssl-server-name-extension"
Posted by Jens Deppe <jd...@pivotal.io>.
Hi Mario,
I did have a question / suggestion about this proposal (possibly on a
different thread). Would you mind responding to that before proceeding
please. I'll just paste it in here too.
> Jens Deppe <jd...@pivotal.io>
> Tue, Nov 19, 4:42 PM
> to dev
> I'd like to add my comment from the original PR here again:
>
>
> Although I support the particular use case, I would prefer the
> implementation being a bit more abstracted. Specifically, if we provided an
> extension point which would allow modification of SSLParameters then we
> wouldn't be coupling to a particular use case. So I'm thinking that the
> user would define (via say a ssl-parameter-extension parameter) a class
> that takes in a SSLParameter and perhaps SSLConfig and whatever else for
> this use-case and does what it needs. The user class would need to
> implement an interface something like this:
>
> public interface SSLParameterExtension {
> SSLParameter modify(SSLParameter, SSLConfig);
> }
>
> I would imagine seeing the user implementation of this being attached to
> SSLConfig.
>
>
> (https://github.com/apache/geode/pull/4310)
>
> I don't mind (mis)using the Server Name field to convey some other
> information, but since it's possible to abstract the specific nature and
> application of that information, I think we should do so. Anyone else who
> looks at the code is going to wonder what the use is especially if the
> consumer of that particular piece of info is going to be provided via an
> external SSLEngine implementation.
>
>
Thanks!
--Jens
On Mon, Dec 9, 2019 at 2:37 AM Mario Ivanac <ma...@est.tech> wrote:
> Hi,
>
> Since this proposal is open for almost three weeks,
> and we have 2 plus one,
>
> We will continue with proposed solution.
>
> Regards,
> Mario
>
> ________________________________
> Šalje: Mario Ivanac <ma...@est.tech>
> Poslano: 19. studenog 2019. 12:26
> Prima: dev@geode.apache.org <de...@geode.apache.org>
> Predmet: Proposal of new config property "ssl-server-name-extension"
>
> Hi geode dev,
>
> as a part of solution for https://issues.apache.org/jira/browse/GEODE-7414
> we would like to introduce new config property "ssl-server-name-extension".
>
> This property will contain generic string, which will be added as Server
> Name Indication (SNI) parameter to Client Hello message.
>
> Do you agree with this proposal?
>
> Thanks,
> Mario
>
Odg: Proposal of new config property "ssl-server-name-extension"
Posted by Mario Ivanac <ma...@est.tech>.
Hi,
Since this proposal is open for almost three weeks,
and we have 2 plus one,
We will continue with proposed solution.
Regards,
Mario
________________________________
Šalje: Mario Ivanac <ma...@est.tech>
Poslano: 19. studenog 2019. 12:26
Prima: dev@geode.apache.org <de...@geode.apache.org>
Predmet: Proposal of new config property "ssl-server-name-extension"
Hi geode dev,
as a part of solution for https://issues.apache.org/jira/browse/GEODE-7414
we would like to introduce new config property "ssl-server-name-extension".
This property will contain generic string, which will be added as Server Name Indication (SNI) parameter to Client Hello message.
Do you agree with this proposal?
Thanks,
Mario
Re: Proposal of new config property "ssl-server-name-extension"
Posted by Bruce Schuchardt <bs...@pivotal.io>.
+1
On 11/19/19 3:26 AM, Mario Ivanac wrote:
> Hi geode dev,
>
> as a part of solution for https://issues.apache.org/jira/browse/GEODE-7414
> we would like to introduce new config property "ssl-server-name-extension".
>
> This property will contain generic string, which will be added as Server Name Indication (SNI) parameter to Client Hello message.
>
> Do you agree with this proposal?
>
> Thanks,
> Mario
>
Odg: Proposal of new config property "ssl-server-name-extension"
Posted by Mario Ivanac <ma...@est.tech>.
Hi Sai,
The security provider main class is configured through a java security file:
-Djava.security.properties=custom-security.file
Where we set:
security.provider.1=my.security.provider.class
The security provider is packaged as a .jar and added to the classpath. The security provider code is triggered once the geode default context is initialized, so there is no room to take over the context before that.
Also, the configuration of the TLS handshake message extensions is part of the SSLSocket configuration. I’m not aware of a way to configure this through the context.
BR,
Mario
________________________________
Šalje: Sai Boorlagadda <sa...@gmail.com>
Poslano: 24. studenog 2019. 17:33
Prima: dev@geode.apache.org <de...@geode.apache.org>
Predmet: Re: Proposal of new config property "ssl-server-name-extension"
Hello Mario,
I would like to see if having a custom security provider allows you to
configure the default SSL context to set the SNI?
From your proposal, I see that you have implemented a Java Security
Provider to provide custom KeyManager implementation which distinguishes
certificate based on which the wan-site the peer client is connecting to.
How are you configuring this security provider? I am assuming you have some
bootstrapping code that inserts your security provider before launching
Geode, and also set gemfire property `ssl-use-default-context` to true to
let Geode use the default SSL context. Can this bootstrapping code create
and configure an SSL context with SNI and set it as default context before
launching geode?
This may appear as a workaround but the rationale behind
`ssl-use-default-context` is to delegate the external environment to
configure the SSL context in a required manner and let Geode just use it.
Sai
On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac <ma...@est.tech> wrote:
> Hi geode dev,
>
> as a part of solution for https://issues.apache.org/jira/browse/GEODE-7414
> we would like to introduce new config property "ssl-server-name-extension".
>
> This property will contain generic string, which will be added as Server
> Name Indication (SNI) parameter to Client Hello message.
>
> Do you agree with this proposal?
>
> Thanks,
> Mario
>
Re: Proposal of new config property "ssl-server-name-extension"
Posted by Sai Boorlagadda <sa...@gmail.com>.
Hello Mario,
I would like to see if having a custom security provider allows you to
configure the default SSL context to set the SNI?
From your proposal, I see that you have implemented a Java Security
Provider to provide custom KeyManager implementation which distinguishes
certificate based on which the wan-site the peer client is connecting to.
How are you configuring this security provider? I am assuming you have some
bootstrapping code that inserts your security provider before launching
Geode, and also set gemfire property `ssl-use-default-context` to true to
let Geode use the default SSL context. Can this bootstrapping code create
and configure an SSL context with SNI and set it as default context before
launching geode?
This may appear as a workaround but the rationale behind
`ssl-use-default-context` is to delegate the external environment to
configure the SSL context in a required manner and let Geode just use it.
Sai
On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac <ma...@est.tech> wrote:
> Hi geode dev,
>
> as a part of solution for https://issues.apache.org/jira/browse/GEODE-7414
> we would like to introduce new config property "ssl-server-name-extension".
>
> This property will contain generic string, which will be added as Server
> Name Indication (SNI) parameter to Client Hello message.
>
> Do you agree with this proposal?
>
> Thanks,
> Mario
>