[jira] [Commented] (CASSANDRA-9220) Hostname verification for node-to-node encryption
[
https://issues.apache.org/jira/browse/CASSANDRA-9220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15148541#comment-15148541
]
Stefan Podkowinski commented on CASSANDRA-9220:
---
I've now rebased and fixed the dtest and it is working fine now for me. Please
go ahead if you want to continue review.
> Hostname verification for node-to-node encryption
> -
>
> Key: CASSANDRA-9220
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9220
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Fix For: 3.x
>
> Attachments: sslhostverification-2.0.patch
>
>
> This patch will will introduce a new ssl server option:
> {{require_endpoint_verification}}.
> Setting it will enable hostname verification for inter-node SSL
> communication. This is necessary to prevent man-in-the-middle attacks when
> building a trust chain against a common CA. See
> [here|https://tersesystems.com/2014/03/23/fixing-hostname-verification/] for
> background details.
> Clusters that solely rely on importing all node certificates into each trust
> store (as described
> [here|http://docs.datastax.com/en/cassandra/2.0/cassandra/security/secureSSLCertificates_t.html])
> are not effected.
> Clusters that use the same common CA to sign node certificates are
> potentially affected. In case the CA signing process will allow other parties
> to generate certs for different purposes, those certificates could in turn be
> used for MITM attacks. The provided patch will allow to enable hostname
> verification to make sure not only to check if the cert is valid but also if
> it has been created for the host that we're about to connect.
> Corresponding dtest: [Test for
> CASSANDRA-9220|https://github.com/riptano/cassandra-dtest/pull/237]
> Related patches from the client perspective:
> [Java|https://datastax-oss.atlassian.net/browse/JAVA-716],
> [Python|https://datastax-oss.atlassian.net/browse/PYTHON-296]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9220) Hostname verification for node-to-node encryption
[
https://issues.apache.org/jira/browse/CASSANDRA-9220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15145056#comment-15145056
]
Tyler Hobbs commented on CASSANDRA-9220:
[~spo...@gmail.com] should we block this on CASSANDRA-10508, then?
> Hostname verification for node-to-node encryption
> -
>
> Key: CASSANDRA-9220
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9220
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Fix For: 3.x
>
> Attachments: sslhostverification-2.0.patch
>
>
> This patch will will introduce a new ssl server option:
> {{require_endpoint_verification}}.
> Setting it will enable hostname verification for inter-node SSL
> communication. This is necessary to prevent man-in-the-middle attacks when
> building a trust chain against a common CA. See
> [here|https://tersesystems.com/2014/03/23/fixing-hostname-verification/] for
> background details.
> Clusters that solely rely on importing all node certificates into each trust
> store (as described
> [here|http://docs.datastax.com/en/cassandra/2.0/cassandra/security/secureSSLCertificates_t.html])
> are not effected.
> Clusters that use the same common CA to sign node certificates are
> potentially affected. In case the CA signing process will allow other parties
> to generate certs for different purposes, those certificates could in turn be
> used for MITM attacks. The provided patch will allow to enable hostname
> verification to make sure not only to check if the cert is valid but also if
> it has been created for the host that we're about to connect.
> Corresponding dtest: [Test for
> CASSANDRA-9220|https://github.com/riptano/cassandra-dtest/pull/237]
> Github:
> 2.0 ->
> [diff|https://github.com/apache/cassandra/compare/cassandra-2.0...spodkowinski:feat/sslhostverification],
>
> [patch|https://github.com/apache/cassandra/compare/cassandra-2.0...spodkowinski:feat/sslhostverification.patch],
> Trunk ->
> [diff|https://github.com/apache/cassandra/compare/trunk...spodkowinski:feat/sslhostverification],
>
> [patch|https://github.com/apache/cassandra/compare/trunk...spodkowinski:feat/sslhostverification.patch]
> Related patches from the client perspective:
> [Java|https://datastax-oss.atlassian.net/browse/JAVA-716],
> [Python|https://datastax-oss.atlassian.net/browse/PYTHON-296]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9220) Hostname verification for node-to-node encryption
[
https://issues.apache.org/jira/browse/CASSANDRA-9220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14955120#comment-14955120
]
Stefan Podkowinski commented on CASSANDRA-9220:
---
The [corresponding dtest|https://github.com/riptano/cassandra-dtest/pull/237]
will currently fail on my machine. For some reason it will only succeed after
adding the SHA256 cipher suite versions to the whitelist in EncryptionOptions.
I've added some general thoughts on handling those options in CASSANDRA-10508.
> Hostname verification for node-to-node encryption
> -
>
> Key: CASSANDRA-9220
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9220
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Fix For: 3.x
>
> Attachments: sslhostverification-2.0.patch
>
>
> This patch will will introduce a new ssl server option:
> {{require_endpoint_verification}}.
> Setting it will enable hostname verification for inter-node SSL
> communication. This is necessary to prevent man-in-the-middle attacks when
> building a trust chain against a common CA. See
> [here|https://tersesystems.com/2014/03/23/fixing-hostname-verification/] for
> background details.
> Clusters that solely rely on importing all node certificates into each trust
> store (as described
> [here|http://docs.datastax.com/en/cassandra/2.0/cassandra/security/secureSSLCertificates_t.html])
> are not effected.
> Clusters that use the same common CA to sign node certificates are
> potentially affected. In case the CA signing process will allow other parties
> to generate certs for different purposes, those certificates could in turn be
> used for MITM attacks. The provided patch will allow to enable hostname
> verification to make sure not only to check if the cert is valid but also if
> it has been created for the host that we're about to connect.
> Corresponding dtest: [Test for
> CASSANDRA-9220|https://github.com/riptano/cassandra-dtest/pull/237]
> Github:
> 2.0 ->
> [diff|https://github.com/apache/cassandra/compare/cassandra-2.0...spodkowinski:feat/sslhostverification],
>
> [patch|https://github.com/apache/cassandra/compare/cassandra-2.0...spodkowinski:feat/sslhostverification.patch],
> Trunk ->
> [diff|https://github.com/apache/cassandra/compare/trunk...spodkowinski:feat/sslhostverification],
>
> [patch|https://github.com/apache/cassandra/compare/trunk...spodkowinski:feat/sslhostverification.patch]
> Related patches from the client perspective:
> [Java|https://datastax-oss.atlassian.net/browse/JAVA-716],
> [Python|https://datastax-oss.atlassian.net/browse/PYTHON-296]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9220) Hostname verification for node-to-node encryption
[
https://issues.apache.org/jira/browse/CASSANDRA-9220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14950842#comment-14950842
]
Jeremiah Jordan commented on CASSANDRA-9220:
Should we add it commented out to the client_encryption_options?
This patch doesn't set this on Thrift server SSL connections. Those changes
would go in o.a.c.t.CustomTThreadPoolServer if we care.
> Hostname verification for node-to-node encryption
> -
>
> Key: CASSANDRA-9220
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9220
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Fix For: 3.x
>
> Attachments: sslhostverification-2.0.patch
>
>
> This patch will will introduce a new ssl server option:
> {{require_endpoint_verification}}.
> Setting it will enable hostname verification for inter-node SSL
> communication. This is necessary to prevent man-in-the-middle attacks when
> building a trust chain against a common CA. See
> [here|https://tersesystems.com/2014/03/23/fixing-hostname-verification/] for
> background details.
> Clusters that solely rely on importing all node certificates into each trust
> store (as described
> [here|http://docs.datastax.com/en/cassandra/2.0/cassandra/security/secureSSLCertificates_t.html])
> are not effected.
> Clusters that use the same common CA to sign node certificates are
> potentially affected. In case the CA signing process will allow other parties
> to generate certs for different purposes, those certificates could in turn be
> used for MITM attacks. The provided patch will allow to enable hostname
> verification to make sure not only to check if the cert is valid but also if
> it has been created for the host that we're about to connect.
> Corresponding dtest: [Test for
> CASSANDRA-9220|https://github.com/riptano/cassandra-dtest/pull/237]
> Github:
> 2.0 ->
> [diff|https://github.com/apache/cassandra/compare/cassandra-2.0...spodkowinski:feat/sslhostverification],
>
> [patch|https://github.com/apache/cassandra/compare/cassandra-2.0...spodkowinski:feat/sslhostverification.patch],
> Trunk ->
> [diff|https://github.com/apache/cassandra/compare/trunk...spodkowinski:feat/sslhostverification],
>
> [patch|https://github.com/apache/cassandra/compare/trunk...spodkowinski:feat/sslhostverification.patch]
> Related patches from the client perspective:
> [Java|https://datastax-oss.atlassian.net/browse/JAVA-716],
> [Python|https://datastax-oss.atlassian.net/browse/PYTHON-296]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9220) Hostname verification for node-to-node encryption
[
https://issues.apache.org/jira/browse/CASSANDRA-9220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14950833#comment-14950833
]
Tyler Hobbs commented on CASSANDRA-9220:
Sorry, this fell off my radar. The server-side patch looks good to me, and the
driver level work can be done separately, in any case.
I've pushed a [branch|https://github.com/thobbs/cassandra/tree/CASSANDRA-9220]
with the changes and one minor difference: I've lowered the error-level log to
a warning in MessagingService.
Pending CI runs:
*
[testall|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-9220-testall/]
*
[dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-9220-dtest/]
If anybody else is more familiar with SSL than me and would like to
double-check this, I would appreciate it.
> Hostname verification for node-to-node encryption
> -
>
> Key: CASSANDRA-9220
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9220
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Fix For: 3.x
>
> Attachments: sslhostverification-2.0.patch
>
>
> This patch will will introduce a new ssl server option:
> {{require_endpoint_verification}}.
> Setting it will enable hostname verification for inter-node SSL
> communication. This is necessary to prevent man-in-the-middle attacks when
> building a trust chain against a common CA. See
> [here|https://tersesystems.com/2014/03/23/fixing-hostname-verification/] for
> background details.
> Clusters that solely rely on importing all node certificates into each trust
> store (as described
> [here|http://docs.datastax.com/en/cassandra/2.0/cassandra/security/secureSSLCertificates_t.html])
> are not effected.
> Clusters that use the same common CA to sign node certificates are
> potentially affected. In case the CA signing process will allow other parties
> to generate certs for different purposes, those certificates could in turn be
> used for MITM attacks. The provided patch will allow to enable hostname
> verification to make sure not only to check if the cert is valid but also if
> it has been created for the host that we're about to connect.
> Corresponding dtest: [Test for
> CASSANDRA-9220|https://github.com/riptano/cassandra-dtest/pull/237]
> Github:
> 2.0 ->
> [diff|https://github.com/apache/cassandra/compare/cassandra-2.0...spodkowinski:feat/sslhostverification],
>
> [patch|https://github.com/apache/cassandra/compare/cassandra-2.0...spodkowinski:feat/sslhostverification.patch],
> Trunk ->
> [diff|https://github.com/apache/cassandra/compare/trunk...spodkowinski:feat/sslhostverification],
>
> [patch|https://github.com/apache/cassandra/compare/trunk...spodkowinski:feat/sslhostverification.patch]
> Related patches from the client perspective:
> [Java|https://datastax-oss.atlassian.net/browse/JAVA-716],
> [Python|https://datastax-oss.atlassian.net/browse/PYTHON-296]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9220) Hostname verification for node-to-node encryption
[
https://issues.apache.org/jira/browse/CASSANDRA-9220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14559764#comment-14559764
]
Stefan Podkowinski commented on CASSANDRA-9220:
---
In response to [~thobbs] notes on the *Python* patch:
The
[match_hostname|https://docs.python.org/2/library/ssl.html#ssl.match_hostname]
function has already been backported to Python 2.7.9 ([PEP
466|https://www.python.org/dev/peps/pep-0466/]). But most distros won't use the
latest version yet and some people may even use 2.6. How about letting users
install the backport them self in such cases, instead of bundling it and try to
{{import backport.ssl_match_hostname}} in case {{import ssl.match_hostname}}
fails?
Using a mix of hostnames and IPs gathered from configs and discovery can indeed
be a problem. But saying {{match_hostname}} doesn't work with IPs isn't
entirely true. It only supports DNS when using {{subjectAltName}} extensions,
but will still fallback to the CN, which can also be an IP. See
[source|https://bitbucket.org/brandon/backports.ssl_match_hostname/src/f3a8371753678d38c20036713da5bf32b7da941e/backports/ssl_match_hostname/__init__.py?at=default]
for details. I used IPs exclusively this way for the [implemented
dtests|https://github.com/spodkowinski/cassandra-dtest/blob/feat/nativetransportssl/sslnativetransport_test.py].
In practice, you'll likely end up with certs using both DNS and IP.
> Hostname verification for node-to-node encryption
> -
>
> Key: CASSANDRA-9220
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9220
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Fix For: 3.x
>
> Attachments: sslhostverification-2.0.patch
>
>
> This patch will will introduce a new ssl server option:
> {{require_endpoint_verification}}.
> Setting it will enable hostname verification for inter-node SSL
> communication. This is necessary to prevent man-in-the-middle attacks when
> building a trust chain against a common CA. See
> [here|https://tersesystems.com/2014/03/23/fixing-hostname-verification/] for
> background details.
> Clusters that solely rely on importing all node certificates into each trust
> store (as described
> [here|http://docs.datastax.com/en/cassandra/2.0/cassandra/security/secureSSLCertificates_t.html])
> are not effected.
> Clusters that use the same common CA to sign node certificates are
> potentially affected. In case the CA signing process will allow other parties
> to generate certs for different purposes, those certificates could in turn be
> used for MITM attacks. The provided patch will allow to enable hostname
> verification to make sure not only to check if the cert is valid but also if
> it has been created for the host that we're about to connect.
> Corresponding dtest: [Test for
> CASSANDRA-9220|https://github.com/riptano/cassandra-dtest/pull/237]
> Github:
> 2.0 ->
> [diff|https://github.com/apache/cassandra/compare/cassandra-2.0...spodkowinski:feat/sslhostverification],
>
> [patch|https://github.com/apache/cassandra/compare/cassandra-2.0...spodkowinski:feat/sslhostverification.patch],
> Trunk ->
> [diff|https://github.com/apache/cassandra/compare/trunk...spodkowinski:feat/sslhostverification],
>
> [patch|https://github.com/apache/cassandra/compare/trunk...spodkowinski:feat/sslhostverification.patch]
> Related patches from the client perspective:
> [Java|https://datastax-oss.atlassian.net/browse/JAVA-716],
> [Python|https://datastax-oss.atlassian.net/browse/PYTHON-296]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9220) Hostname verification for node-to-node encryption
[
https://issues.apache.org/jira/browse/CASSANDRA-9220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14559209#comment-14559209
]
Tyler Hobbs commented on CASSANDRA-9220:
There are a couple of problems with this on the python side (which means cqlsh
is affected).
First, the {{match_hostname()}} function is only available in Python 3.2+, and
probably 95% of users are running Python 2. However, there is a
[backport|https://pypi.python.org/pypi/backports.ssl_match_hostname] of this to
Python 2, so we could potentially bundle this with cqlsh (need to look into the
license compatibility).
The second problem is that {{match_hostname()}} doesn't support IP addresses.
This isn't a problem for hosts that are explicitly connected to, because you
can easily provide a hostname. However, when other nodes are discovered
through {{system.peers}}, we'll only have an IP address, not a hostname. I'm
not sure what the best fix is here.
Although I would prefer not to have these problems, I don't think they're
blockers for committing this. Hostname verification would be nice even if it's
not supported by cqlsh in most cases. cqlsh would still continue to function,
it just wouldn't have the full level of security.
> Hostname verification for node-to-node encryption
> -
>
> Key: CASSANDRA-9220
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9220
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Fix For: 3.x
>
> Attachments: sslhostverification-2.0.patch
>
>
> This patch will will introduce a new ssl server option:
> {{require_endpoint_verification}}.
> Setting it will enable hostname verification for inter-node SSL
> communication. This is necessary to prevent man-in-the-middle attacks when
> building a trust chain against a common CA. See
> [here|https://tersesystems.com/2014/03/23/fixing-hostname-verification/] for
> background details.
> Clusters that solely rely on importing all node certificates into each trust
> store (as described
> [here|http://docs.datastax.com/en/cassandra/2.0/cassandra/security/secureSSLCertificates_t.html])
> are not effected.
> Clusters that use the same common CA to sign node certificates are
> potentially affected. In case the CA signing process will allow other parties
> to generate certs for different purposes, those certificates could in turn be
> used for MITM attacks. The provided patch will allow to enable hostname
> verification to make sure not only to check if the cert is valid but also if
> it has been created for the host that we're about to connect.
> Corresponding dtest: [Test for
> CASSANDRA-9220|https://github.com/riptano/cassandra-dtest/pull/237]
> Github:
> 2.0 ->
> [diff|https://github.com/apache/cassandra/compare/cassandra-2.0...spodkowinski:feat/sslhostverification],
>
> [patch|https://github.com/apache/cassandra/compare/cassandra-2.0...spodkowinski:feat/sslhostverification.patch],
> Trunk ->
> [diff|https://github.com/apache/cassandra/compare/trunk...spodkowinski:feat/sslhostverification],
>
> [patch|https://github.com/apache/cassandra/compare/trunk...spodkowinski:feat/sslhostverification.patch]
> Related patches from the client perspective:
> [Java|https://datastax-oss.atlassian.net/browse/JAVA-716],
> [Python|https://datastax-oss.atlassian.net/browse/PYTHON-296]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
