cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Per Otterström (JIRA) <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13404) Hostname verification for client-to-node encryption
Date Wed, 20 Sep 2017 11:56:00 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message