Odg: Odg: Proposal of new config property "ssl-server-name-extension"
Hi,
I agree with your proposal/question,
and implementation will follow it.
BR,
Mario
Šalje: Jens Deppe
Poslano: 9. prosinca 2019. 15:55
Prima: dev@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
> 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 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
> Poslano: 19. studenog 2019. 12:26
> Prima: dev@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"
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
> 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 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
> Poslano: 19. studenog 2019. 12:26
> Prima: dev@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"
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 Poslano: 19. studenog 2019. 12:26 Prima: dev@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"
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 Poslano: 24. studenog 2019. 17:33 Prima: dev@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 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"
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
Poslano: 21. studenog 2019. 4:29
Prima: dev@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 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 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 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 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
> > 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 >
> > > > > 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".
> > > > > >
Odg: Proposal of new config property "ssl-server-name-extension"
Hi, all connections will use ssl-server-name-extension as part of Client Hello. BR, Mario Šalje: Dan Smith Poslano: 19. studenog 2019. 22:17 Prima: dev@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 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 > 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 | cbl...@pivotal.io >
Re: Odg: Odg: Proposal of new config property "ssl-server-name-extension"
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 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 > *Poslano:* 19. studenog 2019. 18:20 > *Prima:* Mario Ivanac > *Kopija:* dev@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 > 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=DwMF-g=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw=TeO8Y4MHxN-HWthX0kIhmTbHjxbnon-82BZ-g9Q6TDI=GG4kW5SuTjSCV707Igt5WbMQyay_8vOtB9nH8cLBgAM=PjLj2CJYNHbQUiMKrd-FKMqwbuxVERJifxQWpM4HM8k=> > > > BR, > Mario > -- > *Šalje:* Charlie Black > *Poslano:* 19. studenog 2019. 17:24 > *Prima:* dev@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 > 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=DwMF-g=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw=TeO8Y4MHxN-HWthX0kIhmTbHjxbnon-82BZ-g9Q6TDI=GG4kW5SuTjSCV707Igt5WbMQyay_8vOtB9nH8cLBgAM=4h7HHiRlRX_Cw8mVGuVfzHgfUbKul07BjaV1CVE3_H8=> > > 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 | cbl...@pivotal.io > > > > -- > Charlie Black | cbl...@pivotal.io > -- Charlie Black | cbl...@pivotal.io
Odg: Odg: Proposal of new config property "ssl-server-name-extension"
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 Poslano: 19. studenog 2019. 18:20 Prima: Mario Ivanac Kopija: dev@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 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=DwMF-g=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw=TeO8Y4MHxN-HWthX0kIhmTbHjxbnon-82BZ-g9Q6TDI=GG4kW5SuTjSCV707Igt5WbMQyay_8vOtB9nH8cLBgAM=PjLj2CJYNHbQUiMKrd-FKMqwbuxVERJifxQWpM4HM8k=> BR, Mario Šalje: Charlie Black mailto:cbl...@pivotal.io>> Poslano: 19. studenog 2019. 17:24 Prima: dev@geode.apache.org<mailto:dev@geode.apache.org> mailto:dev@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 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=DwMF-g=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw=TeO8Y4MHxN-HWthX0kIhmTbHjxbnon-82BZ-g9Q6TDI=GG4kW5SuTjSCV707Igt5WbMQyay_8vOtB9nH8cLBgAM=4h7HHiRlRX_Cw8mVGuVfzHgfUbKul07BjaV1CVE3_H8=> > 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 | cbl...@pivotal.io<mailto:cbl...@pivotal.io> -- Charlie Black | cbl...@pivotal.io<mailto:cbl...@pivotal.io>
Odg: Proposal of new config property "ssl-server-name-extension"
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 Poslano: 19. studenog 2019. 17:24 Prima: dev@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 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 | cbl...@pivotal.io
