[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458359#comment-16458359 ] Per Otterström commented on CASSANDRA-13404: Thanks, and I appreciate your patience with me. :) The patch is small, so shouldn't be to much. One thing I should mention though. In the dtests I'm using the openssl command to convert keys to pem format. I suppose this brings in a "new dependency" to the dtests. Is that OK? > 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: Per Otterström >Priority: Major > Fix For: 4.x > > Attachments: 13404-trunk-v2.patch, 13404-trunk.txt > > > Similarily to CASSANDRA-9220, Cassandra should support hostname verification > for client-node connections. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16450252#comment-16450252 ] Jason Brown commented on CASSANDRA-13404: - I'll review this with a fresh perspective, as well, [~eperott]. If anything, thanks for the persistence ;) > 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: Per Otterström >Priority: Major > Fix For: 4.x > > Attachments: 13404-trunk-v2.patch, 13404-trunk.txt > > > Similarily to CASSANDRA-9220, Cassandra should support hostname verification > for client-node connections. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16450025#comment-16450025 ] Per Otterström commented on CASSANDRA-13404: Taking another stab at this ticket. Attaching an updated patch set and some dtests to go with that. Short recap: * I want to add hostname validation on server side to verify client IP matches SAN field in client certificate. * Several concerns were raised on initial patch, "does it add value", "setting incoming IP on the SSLHandler", "added complexity for users". * A second patch based on a plug-in approach was created. While this approach has some interesting benefits, it is a bit overkill for this. Some comments on the updated patch: * SslHandler will get client host info only when endpoint-verification is enabled, very similar to the setup of server-server communication. When require_endpoint_verification option is not enabled, behavior will remain unchanged. * The require_endpoint_verification is already accepted for client-server configuration, just currently unused and silently discared. Adding this property to the client_encryption_options section should be manageble for our users in terms of complexity. * The fact that this patch-set give the wanted effect is verified with the provided dtests. * IMO the value is well argued in previous comments. When tickets like CASSANDRA-13971 gets merged, a growing number of useres will have access to an infrastructure that manages keys and certificates. Then hostname validation will be a common task. Patch for trunk: https://github.com/eperott/cassandra/tree/13404-trunk Dtests: https://github.com/eperott/cassandra-dtest/tree/13404-trunk CircleCI (unit tests only): https://circleci.com/workflow-run/c29a6caf-1eeb-408d-a424-1ffbcaf9477d > 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: Per Otterström >Priority: Major > Fix For: 4.x > > Attachments: 13404-trunk-v2.patch, 13404-trunk.txt > > > Similarily to CASSANDRA-9220, Cassandra should support hostname verification > for client-node connections. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16180427#comment-16180427 ] Per Otterström commented on CASSANDRA-13404: 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
[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16176162#comment-16176162 ] Stefan Podkowinski commented on CASSANDRA-13404: We already have a plugable interface for authentication: IAuthenticator. But it's working on the application layer, i.e. the tls connection will already be established at this point. The IAuthenticator interface and the SASL based negotiation process is pretty flexible though. You can already create and use your own implementation that would validate any provided certificate as you see fit. But then you'd also have to implement this on the client side as well and I'm not sure if that would be possible for you. > 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
[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16175984#comment-16175984 ] Jeff Jirsa commented on CASSANDRA-13404: Before we jump into the code, I'd like to see some consensus among committers. [~spo...@gmail.com], what do you think about a pluggable interface that would allow these folks to extend client auth to support a feature like this? I have to admit I haven't read the code, and I don't know if there's a natural extension point, but are you ok with it in theory (it sounds like Jason is ok with it in theory)? > 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
[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16175980#comment-16175980 ] Per Otterström commented on CASSANDRA-13404: That is an interesting approach. A bit overkill for this small change in itself. And if we argue that the "require_endpoint_verification" option easily could get misunderstood or misconfigured, then I think this will present far more opportunities to get it wrong. Then again, making this pluggable would be very powerful and I can think of a few useful ways to use that. On the downside, this approach will not encourage users to provide security improvements to the community, but instead keep that in their own custom plugins. I'm willing to work out an example on how such a plugin API could look. Unless someone else was planning to grab this task of course? > 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
[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173535#comment-16173535 ] Jason Brown commented on CASSANDRA-13404: - [~jjirsa] I am fine with that idea. > 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
[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[
https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173429#comment-16173429
]
Jeff Jirsa commented on CASSANDRA-13404:
Is there another way to implement the ip restrictions here that would work?
Could we extend the auth APIs to provide for something like the
{{IInternodeAuthenticator}} for client connections, and then people with
atypical-but-valid requirements like this can implement their own pluggable
client auth library?
> 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
[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173391#comment-16173391 ] Per Otterström commented on CASSANDRA-13404: OK, I can see where this is going. And I appreciate the time you all spent on this topic! Can't say I'm happy with the conclusion, then again I understand that this feature has limited value to the average user. My final attempt to convince you all. Please have a quick look at the following references which I got from my security team: https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Use_a_Certificate_That_Supports_Required_Domain_Names https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Client-Side_Certificates Let me know if its changing your mind. Otherwise I'll drop it. For this time. ;-) > 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
[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173099#comment-16173099 ] Stefan Podkowinski commented on CASSANDRA-13404: Using client certificates sounds like a very unconventional way to control access at network level. Why don't you just lock down any cluster network access to addresses and subnets on the firewall, instead of authorizing hosts via your key management service, by creating host specific client certificates that you depend on to be refused if not used from a matching IP? As already mentioned, the hostname verification process has been designed to prevent men-in-the-middle attacks, which doesn't really apply here. Although this is a small patch, I'm not convinced how this would benefit the broader user community, without adding more complexity and security options that can be misunderstood and misconfigured. > 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
[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173059#comment-16173059 ] Per Otterström commented on CASSANDRA-13404: Let me elaborate further on the context where I think this makes sense. We embed Cassandra in our products which are deployed on customer premises around the world, including regions where corruption is a common problem. Internal fraud is often, by far, the biggest security issue for these customers. History taught us that people have both the skill and imagination as they try to trick our systems when there is an incitement; money. We can advice customers to hire staff they trust, but as you can imagine it is not that easy. Without hostname verification on the server side it is easy for someone with access to copy certificates from one of the client application hosts to another host on the network and connect to the server. Or, a person with access to the datacenter can replace a "broken" disk and then extract certificates from it. Or, you can shut down a VM, mount the disk image in another VM and extract the certificates. Hostname verification on the server side is not going to be the thing that finally makes it impossible to manipulate data in Cassandra, but it is yet another barrier that will limit the options available to an attacker. bq. By the time an attacker can copy a cert, can't they also spoof an IP address, as well? To properly spoof an IP address and carry out a handshake you would have to implement ARP poisoning. There are ways to create barriers for this as well making it harder for an attacker. I don't think we should assume that an attacker can do IP spoofing just because he can steal a certificate. The security level of a system is not going to come down to one single barrier, but all barriers together. bq. I'll be honest, I'm unconfortable with the patch - taking the incoming IP address and passing that directly into the SslHandler just seems wrong. I fail to see the harm. The change is small and contained. If you have the time, can you elaborate a bit? Or do you think there is some setup of tests that would bring confidence into this? Btw, I'd be happy to rebase the patch and work on dtests, depending on the conclusions here of course. > 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
[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[
https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16172394#comment-16172394
]
Jason Brown commented on CASSANDRA-13404:
-
In client-side endpoint verification, the client knows the server's hostname,
retrieves the server's cert, and compares the hostname it already has with
what's in the cert. In other words, it uses a piece of information it already
had as well as a piece of information from the server.
In the case of server-side enpoint verification, what you are proposing is to
use the client IP address from the incoming socket as the hostname and then a
cert that will also be provided by the client. Thus, both pieces of information
that the server uses to verify are coming from the client. The certificate is
cryptographically signed, but the IP address is not. This means that the IP
address could potentially be spoofed and will not satisfy the original
requirement of "preventing certificates from being copied and used elsewhere".
bq. Hostname verification on the server side would improve security in that no
one is able to copy a certificate from a client node to another location, and
then use it to manipulate data in Cassandra.
By the time an attacker can copy a cert, can't they also spoof an IP address,
as well?
I'll be honest, I'm unconfortable with the patch - taking the incoming IP
address and passing that directly into the {{SslHandler}} just seems wrong.
More importantly, I don't think this solution really solves your problem of
ensuring that only legit clients can connect as IP addresses can be spoofed.
I'm -1 unless [~spo...@gmail.com] or anybody else has a convincing argument.
/cc [~smitchelus] of the core netty team, as he and i discussed this issue at
length.
> 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
[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[
https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16171617#comment-16171617
]
Jason Brown commented on CASSANDRA-13404:
-
[~eperott] and [~Jan Karlsson] I was planning on coming back to this after
CASSANDRA-8457, and now that it's out of the way we can pick it up. At a
minimum we'll need to rebase the patch (should be trivial), and we should
probably add some dtests. New dtests should probably go in
{{native_transport_ssl_test.py}}, and there's examples in
{{sslnodetonode_test.py}} for doing TLS-type stuff like endpoint verification.
> 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
[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16171305#comment-16171305 ] Per Otterström commented on CASSANDRA-13404: Let me (colleague of Jan) add a little context to describe why we want hostname verification on the server side. In our deployments all peers (both clients and servers) will automatically get unique certificates signed for them. This allow us to limit access such that only trusted clients can connect to Cassandra. Hostname verification on the server side would improve security in that no one is able to copy a certificate from a client node to another location, and then use it to manipulate data in Cassandra. The patch provided by Jan contain two different changes: - The first is about setting the endpoint identification algorithm. This seem pretty straight forward as it is optional and in line with what we already have on the server-to-server communication. - The second is about passing the remote peer information into the SSLEngine as it is created. This is necessary to make remote peer information available to the TrustManager when it is time to validate the certificate chain. And so without this second modification, the first change doesn't make much sense. I understand this change is in conflict with a potential performance improvement by reusing SSLContext's, but as Jan is pointing out, this patch set is only associating peer specific data with the SSLEngine's created from the SSLContext. The SSLContext itself could still be reused. I understand this functionality is valuable to a very small group of users, but as it is optional I can not see the harm of adding it. Thoughts? > 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
[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[
https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15958876#comment-15958876
]
Jan Karlsson commented on CASSANDRA-13404:
--
It is good that you made the distinction that MiM is not something that this
ticket aims to solve. Instead this ticket allows you to bind certificates to
certain hosts to make it less vulnerable.
Applications which have to worry about rogue clients can use this on top of
application side authentication as an extra layer of security and have broader
control over the clients that connect to their server.
{Quote}
I think it was mentioned somewhere that reusing SSLContext instances would be
preferable in the future due to performance reasons. We'd have to change the
code to either return a shared or a newly created instance if we would add this
feature.
{Quote}
Could you elaborate on this? Are we not using the same SSLContext and
retrieving the engine from it?
> 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.3.15#6346)
[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15956937#comment-15956937 ] Stefan Podkowinski commented on CASSANDRA-13404: I think it was mentioned somewhere that reusing SSLContext instances would be preferable in the future due to performance reasons. We'd have to change the code to either return a shared or a newly created instance if we would add this feature. The main motivation for CASSANDRA-9220 and related client tickets was to prevent men-in-the-middle attacks. If you send your login credentials, you have to make sure that the connection hasn't been compromised and therefor it's important to verify that the peer is really the server you think you're talking to. This can be done by verifying the trust chain of the certificate and the hostname for which the certificate has been issued for. Once the connection has been verified, the connection confidentiality has been established and there's no point for the server to in turn verify the client certificate again to prevent MiM. The only scenario where it would make sense to verify clients is when you're not able to verify server certificates correctly on the client side. At least the Java and Python driver should now do this correctly (incl. hostnames), but there could be other clients where you'd prefer to verify from server side. But given operational implications (there are usually much more client nodes than cluster nodes in the network) of having to manage a lot of certificates for a potentially elastic number of clients, this would be a quite heavy handed way to address this issue for most users. In this case you probably would want to spend the effort fixing the clients to correctly verify the servers. This doesn't mean I'm -1 here as long as code changes are small, but just wanted to share my thoughts why this hasn't been implemented yet. > 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.3.15#6346)
[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[
https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15956604#comment-15956604
]
Jan Karlsson commented on CASSANDRA-13404:
--
{quote}
To back up and add a bit more context (for myself, if anything), where do you
want to add the additional hostname verification? Can you explain the specific
behaviour you're looking to add?
{quote}
The behaviour I am trying to add is that the server validates that the client
certificate is issued to the IP address/host that the client connects from. You
are correct that this would require require_client_auth to be set as this will
ensure that the server validates the client to begin with. Disabling
require_client_auth while enabling hostname verification will actually not do
anything. We wont validate anything. Do you think we should add a warning
during startup that you cannot have hostname validation without requiring
validation?
{quote}
Further, this would require the database server to know all of the possible
peers that would want to connect to it, before the process starts.
{quote}
Not necessarily, I take the incoming connection, extract the IP, then the
identification algorithm checks whether the SAN in the certificate holds this
IP address.
{quote}
Also, I've spoken with the netty developers, and they said netty currently does
not support (in either netty 4.0 or 4.1) the ability to perform hostname
verification on the server side (either openssl or jdk ssl). Thus, I'm not sure
how you verified your patch behaves correctly.
{quote}
I used the java driver and added [Netty Options |
http://docs.datastax.com/en/drivers/java/2.1/com/datastax/driver/core/NettyOptions.html#afterBootstrapInitialized-io.netty.bootstrap.Bootstrap-]
to change the local address in afterBootstrapInitialized. This allows me to
change what interface I use to connect to C*. Then I used a certificate I had
forged for a different interface and tested to connect to a node. Worked like a
charm. I then applied my patch and got a exception on both the server and the
client side. Lastly i switched which IP address I connected from to the
interface that was specified in the certificate and the exceptions disappeared.
> 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.3.15#6346)
[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15955710#comment-15955710 ] Jason Brown commented on CASSANDRA-13404: - To back up and add a bit more context (for myself, if anything), where do you want to add the additional hostname verification? Can you explain the specific behavior you're looking to add? The attached patch adds hostname verification on the server-side, where we listen for client connections. Adding hostname verification to the server-side of a TLS connection doesn't make much sense without requiring client auth, correct? Further, this would require the database server to know *all* of the possible peers that would want to connect to it, before the process starts. Please let me know if I'm misunderstanding something here. Also, I've spoken with the netty developers, and they said netty currently does not support (in either netty 4.0 or 4.1) the ability to perform hostname verification on the server side (either openssl or jdk ssl). Thus, I'm not sure how you verified your patch behaves correctly. > 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.3.15#6346)
[jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15955039#comment-15955039 ] Jason Brown commented on CASSANDRA-13404: - I'll review this one, and will keep CASSANDRA-10735 in mind as I do. > 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.3.15#6346)
