[
https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180427#comment-16180427
]
Per Otterström edited comment on CASSANDRA-13404 at 9/26/17 8:18 AM:
---------------------------------------------------------------------
It looks to me like it would be possible to do hostname verification using
SASL. But, as SASL happens at the application layer the solution would be more
exposed to security flaws. Further, as you pointed out [~spo...@gmail.com] all
different kinds of clients, including standard tools such as cqlsh, would have
to include custom SASL mechanisms in order to carry out the SASL handshake. To
me this feels a bit like a workaround solution which seem unnecessary when
there are standardized mechanisms for it
In my specific use case it is not a very good fit for other reasons. We are
using a custom Java security provider with its own TrustManagerFactory service,
in all our deployed applications including Cassandra, and it is expecting the
remote peer information (like hostname/IP) to be available for verification
during TLS handshake. In my opinion, this is where hostname verification should
happen.
I still think that the original proposal is the best as it is lightweight and
it improves the security level of Cassandra. The average user will not need
this but the new configuration option can be ignored if you don't need it.
Adding security features like this (there is more to come) will make Cassandra
a more attractive option for deployments where high security is an important
aspect.
I think the plugin approach is OK as well, but I think it has a drawback in
that it doesn't encourage users to contribute their security improvements to
the community.
was (Author: eperott):
It looks to me like it would be possible to do hostname verification using
SASL. But, as SASL happens at the application layer the solution would be more
exposed to security flaws. Further, as you pointed out Stefan Podkowinski all
different kinds of clients, including standard tools such as cqlsh, would have
to include custom SASL mechanisms in order to carry out the SASL handshake. To
me this feels a bit like a workaround solution which seem unnecessary when
there are standardized mechanisms for it
In my specific use case it is not a very good fit for other reasons. We are
using a custom Java security provider with its own TrustManagerFactory service,
in all our deployed applications including Cassandra, and it is expecting the
remote peer information (like hostname/IP) to be available for verification
during TLS handshake. In my opinion, this is where hostname verification should
happen.
I still think that the original proposal is the best as it is lightweight and
it improves the security level of Cassandra. The average user will not need
this but the new configuration option can be ignored if you don't need it.
Adding security features like this (there is more to come) will make Cassandra
a more attractive option for deployments where high security is an important
aspect.
I think the plugin approach is OK as well, but I think it has a drawback in
that it doesn't encourage users to contribute their security improvements to
the community.
> Hostname verification for client-to-node encryption
> ---------------------------------------------------
>
> Key: CASSANDRA-13404
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13404
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Jan Karlsson
> Assignee: Jan Karlsson
> Fix For: 4.x
>
> Attachments: 13404-trunk.txt
>
>
> Similarily to CASSANDRA-9220, Cassandra should support hostname verification
> for client-node connections.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
