You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@kafka.apache.org by Phi Primed <ph...@gmail.com> on 2016/06/01 07:18:53 UTC
SSL certificate CN validation against FQDN in v0.9
I using Kafka v 0.9 with TLS enabled, including client auth.
In
http://www.confluent.io/blog/apache-kafka-security-authorization-authentication-encryption,
it is mentioned that "We need to generate a key and certificate for each
broker and client in the cluster. The common name (CN) of the broker
certificate must match the fully qualified domain name (FQDN) of the server
as the client compares the CN with the DNS domain name to ensure that it is
connecting to the desired broker (instead of a malicious one)."
1) Is there a specific additional configuration parameter to enable this or
does it always happen if the other TLS/SSL parameters are set (as e.g.
shown below) ?
2) Is it possible to make the broker(s) carry out the same check against
client certificates if SSL client auth is enabled ?
Regards,
Phi
listeners=SSL://:9093
authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer
super.users=User:CN=broker1.mydomain.com,OU=ABC,O=XYZ,L=SFO,ST=CA,C=US
ssl.keystore.location=/opt/ssl/kafka.server.keystore.jks
ssl.keystore.password=test1234
ssl.key.password=test1234
ssl.truststore.location=/opt/ssl/kafka.server.truststore.jks
ssl.truststore.password=test1234
ssl.enabled.protocols=TLSv1.2,TLSv1.1,TLSv1
ssl.keystore.type=JKS
ssl.truststore.type=JKS
security.inter.broker.protocol=SSL
ssl.client.auth=required
Re: SSL certificate CN validation against FQDN in v0.9
Posted by Ismael Juma <is...@juma.me.uk>.
To clarify, we are using a property name that matches the JDK name.
Changing the property name would be an incompatible change, so it would
require a period of deprecation. And for people familiar with JDK, it would
be confusing. So, not clear it would be a good thing.
Ismael
On Wed, Jun 1, 2016 at 2:29 PM, Ismael Juma <is...@juma.me.uk> wrote:
> Martin,
>
> What I said is correct, see:
>
> The JDK 8 release supports endpoint identification algorithms for TLS 1.2.
> The algorithm name can be passed to the
> setEndpointIdentificationAlgorithm() method of javax.net.ssl.SSLParameters.
> The following table shows the currently recognized names.
> Endpoint Identification
> Algorithm NameSpecification
> HTTPS http://www.ietf.org/rfc/rfc2818.txt
> LDAPS http://www.ietf.org/rfc/rfc2830.txt
>
>
> https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html
>
> Ismael
>
> On Wed, Jun 1, 2016 at 1:06 PM, Martin Gainty <mg...@hotmail.com> wrote:
>
>> https is a protocol NOT an algorithm..no wonder this causes
>> confusion!ssl.endpoint.identification.algorithmhttps://
>> en.wikipedia.org/wiki/Transport_Layer_Security
>> ismael can you change ssl.endpoint.identification.algorithm property to
>> ssl.endpoint.identification.protocolso the property matches what the
>> accepted definition?
>>
>> Thanks,
>> Martin
>> ______________________________________________
>>
>>
>>
>> > From: ismael@juma.me.uk
>> > Date: Wed, 1 Jun 2016 11:31:58 +0100
>> > Subject: Re: SSL certificate CN validation against FQDN in v0.9
>> > To: users@kafka.apache.org
>> >
>> > Hi Phil,
>> >
>> > You are right that the check is not done by default. We have a couple of
>> > JIRAs tracking that:
>> >
>> > https://issues.apache.org/jira/browse/KAFKA-3665
>> > https://issues.apache.org/jira/browse/KAFKA-3667
>> >
>> > Enabling the check is a matter of setting
>> > `ssl.endpoint.identification.algorithm`
>> > to `https`, but please check the JIRAs for more details.
>> >
>> > Ismael
>> >
>> > On Wed, Jun 1, 2016 at 8:18 AM, Phi Primed <ph...@gmail.com> wrote:
>> >
>> > > I using Kafka v 0.9 with TLS enabled, including client auth.
>> > >
>> > > In
>> > >
>> > >
>> http://www.confluent.io/blog/apache-kafka-security-authorization-authentication-encryption
>> > > ,
>> > > it is mentioned that "We need to generate a key and certificate for
>> each
>> > > broker and client in the cluster. The common name (CN) of the broker
>> > > certificate must match the fully qualified domain name (FQDN) of the
>> server
>> > > as the client compares the CN with the DNS domain name to ensure that
>> it is
>> > > connecting to the desired broker (instead of a malicious one)."
>> > >
>> > > 1) Is there a specific additional configuration parameter to enable
>> this or
>> > > does it always happen if the other TLS/SSL parameters are set (as e.g.
>> > > shown below) ?
>> > >
>> > > 2) Is it possible to make the broker(s) carry out the same check
>> against
>> > > client certificates if SSL client auth is enabled ?
>> > >
>> > > Regards,
>> > > Phi
>> > >
>> > >
>> > > listeners=SSL://:9093
>> > >
>> > > authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer
>> > >
>> > > super.users=User:CN=broker1.mydomain.com
>> ,OU=ABC,O=XYZ,L=SFO,ST=CA,C=US
>> > >
>> > > ssl.keystore.location=/opt/ssl/kafka.server.keystore.jks
>> > > ssl.keystore.password=test1234
>> > > ssl.key.password=test1234
>> > > ssl.truststore.location=/opt/ssl/kafka.server.truststore.jks
>> > > ssl.truststore.password=test1234
>> > >
>> > > ssl.enabled.protocols=TLSv1.2,TLSv1.1,TLSv1
>> > > ssl.keystore.type=JKS
>> > > ssl.truststore.type=JKS
>> > >
>> > > security.inter.broker.protocol=SSL
>> > >
>> > > ssl.client.auth=required
>> > >
>>
>>
>
>
Re: SSL certificate CN validation against FQDN in v0.9
Posted by Ismael Juma <is...@juma.me.uk>.
Martin,
What I said is correct, see:
The JDK 8 release supports endpoint identification algorithms for TLS 1.2.
The algorithm name can be passed to the
setEndpointIdentificationAlgorithm() method
of javax.net.ssl.SSLParameters. The following table shows the currently
recognized names.
Endpoint Identification
Algorithm NameSpecification
HTTPS http://www.ietf.org/rfc/rfc2818.txt
LDAPS http://www.ietf.org/rfc/rfc2830.txt
https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html
Ismael
On Wed, Jun 1, 2016 at 1:06 PM, Martin Gainty <mg...@hotmail.com> wrote:
> https is a protocol NOT an algorithm..no wonder this causes
> confusion!ssl.endpoint.identification.algorithmhttps://
> en.wikipedia.org/wiki/Transport_Layer_Security
> ismael can you change ssl.endpoint.identification.algorithm property to
> ssl.endpoint.identification.protocolso the property matches what the
> accepted definition?
>
> Thanks,
> Martin
> ______________________________________________
>
>
>
> > From: ismael@juma.me.uk
> > Date: Wed, 1 Jun 2016 11:31:58 +0100
> > Subject: Re: SSL certificate CN validation against FQDN in v0.9
> > To: users@kafka.apache.org
> >
> > Hi Phil,
> >
> > You are right that the check is not done by default. We have a couple of
> > JIRAs tracking that:
> >
> > https://issues.apache.org/jira/browse/KAFKA-3665
> > https://issues.apache.org/jira/browse/KAFKA-3667
> >
> > Enabling the check is a matter of setting
> > `ssl.endpoint.identification.algorithm`
> > to `https`, but please check the JIRAs for more details.
> >
> > Ismael
> >
> > On Wed, Jun 1, 2016 at 8:18 AM, Phi Primed <ph...@gmail.com> wrote:
> >
> > > I using Kafka v 0.9 with TLS enabled, including client auth.
> > >
> > > In
> > >
> > >
> http://www.confluent.io/blog/apache-kafka-security-authorization-authentication-encryption
> > > ,
> > > it is mentioned that "We need to generate a key and certificate for
> each
> > > broker and client in the cluster. The common name (CN) of the broker
> > > certificate must match the fully qualified domain name (FQDN) of the
> server
> > > as the client compares the CN with the DNS domain name to ensure that
> it is
> > > connecting to the desired broker (instead of a malicious one)."
> > >
> > > 1) Is there a specific additional configuration parameter to enable
> this or
> > > does it always happen if the other TLS/SSL parameters are set (as e.g.
> > > shown below) ?
> > >
> > > 2) Is it possible to make the broker(s) carry out the same check
> against
> > > client certificates if SSL client auth is enabled ?
> > >
> > > Regards,
> > > Phi
> > >
> > >
> > > listeners=SSL://:9093
> > >
> > > authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer
> > >
> > > super.users=User:CN=broker1.mydomain.com,OU=ABC,O=XYZ,L=SFO,ST=CA,C=US
> > >
> > > ssl.keystore.location=/opt/ssl/kafka.server.keystore.jks
> > > ssl.keystore.password=test1234
> > > ssl.key.password=test1234
> > > ssl.truststore.location=/opt/ssl/kafka.server.truststore.jks
> > > ssl.truststore.password=test1234
> > >
> > > ssl.enabled.protocols=TLSv1.2,TLSv1.1,TLSv1
> > > ssl.keystore.type=JKS
> > > ssl.truststore.type=JKS
> > >
> > > security.inter.broker.protocol=SSL
> > >
> > > ssl.client.auth=required
> > >
>
>
RE: SSL certificate CN validation against FQDN in v0.9
Posted by Martin Gainty <mg...@hotmail.com>.
https is a protocol NOT an algorithm..no wonder this causes confusion!ssl.endpoint.identification.algorithmhttps://en.wikipedia.org/wiki/Transport_Layer_Security
ismael can you change ssl.endpoint.identification.algorithm property to ssl.endpoint.identification.protocolso the property matches what the accepted definition?
Thanks,
Martin
______________________________________________
> From: ismael@juma.me.uk
> Date: Wed, 1 Jun 2016 11:31:58 +0100
> Subject: Re: SSL certificate CN validation against FQDN in v0.9
> To: users@kafka.apache.org
>
> Hi Phil,
>
> You are right that the check is not done by default. We have a couple of
> JIRAs tracking that:
>
> https://issues.apache.org/jira/browse/KAFKA-3665
> https://issues.apache.org/jira/browse/KAFKA-3667
>
> Enabling the check is a matter of setting
> `ssl.endpoint.identification.algorithm`
> to `https`, but please check the JIRAs for more details.
>
> Ismael
>
> On Wed, Jun 1, 2016 at 8:18 AM, Phi Primed <ph...@gmail.com> wrote:
>
> > I using Kafka v 0.9 with TLS enabled, including client auth.
> >
> > In
> >
> > http://www.confluent.io/blog/apache-kafka-security-authorization-authentication-encryption
> > ,
> > it is mentioned that "We need to generate a key and certificate for each
> > broker and client in the cluster. The common name (CN) of the broker
> > certificate must match the fully qualified domain name (FQDN) of the server
> > as the client compares the CN with the DNS domain name to ensure that it is
> > connecting to the desired broker (instead of a malicious one)."
> >
> > 1) Is there a specific additional configuration parameter to enable this or
> > does it always happen if the other TLS/SSL parameters are set (as e.g.
> > shown below) ?
> >
> > 2) Is it possible to make the broker(s) carry out the same check against
> > client certificates if SSL client auth is enabled ?
> >
> > Regards,
> > Phi
> >
> >
> > listeners=SSL://:9093
> >
> > authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer
> >
> > super.users=User:CN=broker1.mydomain.com,OU=ABC,O=XYZ,L=SFO,ST=CA,C=US
> >
> > ssl.keystore.location=/opt/ssl/kafka.server.keystore.jks
> > ssl.keystore.password=test1234
> > ssl.key.password=test1234
> > ssl.truststore.location=/opt/ssl/kafka.server.truststore.jks
> > ssl.truststore.password=test1234
> >
> > ssl.enabled.protocols=TLSv1.2,TLSv1.1,TLSv1
> > ssl.keystore.type=JKS
> > ssl.truststore.type=JKS
> >
> > security.inter.broker.protocol=SSL
> >
> > ssl.client.auth=required
> >
Re: SSL certificate CN validation against FQDN in v0.9
Posted by Ismael Juma <is...@juma.me.uk>.
Hi Phil,
You are right that the check is not done by default. We have a couple of
JIRAs tracking that:
https://issues.apache.org/jira/browse/KAFKA-3665
https://issues.apache.org/jira/browse/KAFKA-3667
Enabling the check is a matter of setting
`ssl.endpoint.identification.algorithm`
to `https`, but please check the JIRAs for more details.
Ismael
On Wed, Jun 1, 2016 at 8:18 AM, Phi Primed <ph...@gmail.com> wrote:
> I using Kafka v 0.9 with TLS enabled, including client auth.
>
> In
>
> http://www.confluent.io/blog/apache-kafka-security-authorization-authentication-encryption
> ,
> it is mentioned that "We need to generate a key and certificate for each
> broker and client in the cluster. The common name (CN) of the broker
> certificate must match the fully qualified domain name (FQDN) of the server
> as the client compares the CN with the DNS domain name to ensure that it is
> connecting to the desired broker (instead of a malicious one)."
>
> 1) Is there a specific additional configuration parameter to enable this or
> does it always happen if the other TLS/SSL parameters are set (as e.g.
> shown below) ?
>
> 2) Is it possible to make the broker(s) carry out the same check against
> client certificates if SSL client auth is enabled ?
>
> Regards,
> Phi
>
>
> listeners=SSL://:9093
>
> authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer
>
> super.users=User:CN=broker1.mydomain.com,OU=ABC,O=XYZ,L=SFO,ST=CA,C=US
>
> ssl.keystore.location=/opt/ssl/kafka.server.keystore.jks
> ssl.keystore.password=test1234
> ssl.key.password=test1234
> ssl.truststore.location=/opt/ssl/kafka.server.truststore.jks
> ssl.truststore.password=test1234
>
> ssl.enabled.protocols=TLSv1.2,TLSv1.1,TLSv1
> ssl.keystore.type=JKS
> ssl.truststore.type=JKS
>
> security.inter.broker.protocol=SSL
>
> ssl.client.auth=required
>
Re: SSL certificate CN validation against FQDN in v0.9
Posted by Gerard Klijs <ge...@dizzit.com>.
We use almost the same properties (the same if you account for defaults),
and have not seen any check whether the FQDN matches the CN, as it's al
working without matching names. It seems the requirement is only needed if
you use SASL_SSL as security protocol, which from you config you don't seem
to do (just SSL).
On Wed, Jun 1, 2016 at 9:19 AM Phi Primed <ph...@gmail.com> wrote:
> I using Kafka v 0.9 with TLS enabled, including client auth.
>
> In
>
> http://www.confluent.io/blog/apache-kafka-security-authorization-authentication-encryption
> ,
> it is mentioned that "We need to generate a key and certificate for each
> broker and client in the cluster. The common name (CN) of the broker
> certificate must match the fully qualified domain name (FQDN) of the server
> as the client compares the CN with the DNS domain name to ensure that it is
> connecting to the desired broker (instead of a malicious one)."
>
> 1) Is there a specific additional configuration parameter to enable this or
> does it always happen if the other TLS/SSL parameters are set (as e.g.
> shown below) ?
>
> 2) Is it possible to make the broker(s) carry out the same check against
> client certificates if SSL client auth is enabled ?
>
> Regards,
> Phi
>
>
> listeners=SSL://:9093
>
> authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer
>
> super.users=User:CN=broker1.mydomain.com,OU=ABC,O=XYZ,L=SFO,ST=CA,C=US
>
> ssl.keystore.location=/opt/ssl/kafka.server.keystore.jks
> ssl.keystore.password=test1234
> ssl.key.password=test1234
> ssl.truststore.location=/opt/ssl/kafka.server.truststore.jks
> ssl.truststore.password=test1234
>
> ssl.enabled.protocols=TLSv1.2,TLSv1.1,TLSv1
> ssl.keystore.type=JKS
> ssl.truststore.type=JKS
>
> security.inter.broker.protocol=SSL
>
> ssl.client.auth=required
>