RE: Issue in internode encryption in cassandra

[Bastien DINE]

Hi Ashwini,

On all my nodes, I’m installing the additional jce policy
https://support.datastax.com/hc/en-us/articles/204226129-Receiving-error-Caused-by-java-lang-IllegalArgumentException-Cannot-support-TLS-RSA-WITH-AES-256-CBC-SHA-with-currently-installed-providers-on-DSE-startup-after-setting-up-client-to-node-encryption

Then I’m generating one key / certificate on each of my node, exporting public 
part and store it in a truststore of other nodes and configure cassandra.yaml
Datastax documentation is pretty clear :
https://docs.datastax.com/en/cassandra/2.1/cassandra/security/secureSSLCertificates_t.html
https://docs.datastax.com/en/cassandra/2.1/cassandra/security/secureSSLNodeToNode_t.html

Hope its helps,
Regards,

De : Ashwini Mhatre (asmhatre) [mailto:asmha...@cisco.com]
Envoyé : mercredi 3 août 2016 12:25
À : user@cassandra.apache.org
Cc : Keshava H P (kehp); PRABHJOT KAUR (prabhkau)
Objet : Re: Issue in internode encryption in cassandra

Hi,
Is any one have any hint regarding node to node encryption .


Regards,
Ashwini Mhatre

From: asmhatre <asmha...@cisco.com<mailto:asmha...@cisco.com>>
Reply-To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" 
<user@cassandra.apache.org<mailto:user@cassandra.apache.org>>
Date: Monday, 25 July 2016 at 4:15 PM
To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" 
<user@cassandra.apache.org<mailto:user@cassandra.apache.org>>
Subject: Issue in internode encryption in cassandra

I am using internode encryption in cassandra, with self signed CA it works 
fine. but with other product CA m getting this error "Filtering out 
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as it 
isnt supported by the socket”

Re: Issue in internode encryption in cassandra

[Ashwini Mhatre (asmhatre)]

Hi,
Is any one have any hint regarding node to node encryption .


Regards,
Ashwini Mhatre

From: asmhatre <asmha...@cisco.com<mailto:asmha...@cisco.com>>
Reply-To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" 
<user@cassandra.apache.org<mailto:user@cassandra.apache.org>>
Date: Monday, 25 July 2016 at 4:15 PM
To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" 
<user@cassandra.apache.org<mailto:user@cassandra.apache.org>>
Subject: Issue in internode encryption in cassandra

I am using internode encryption in cassandra, with self signed CA it works 
fine. but with other product CA m getting this error "Filtering out 
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as it 
isnt supported by the socket”

Re: Issue in internode encryption in cassandra

[Nate McCall]

>
>
> I am using internode encryption in cassandra, with self signed CA it
works fine. but with other product CA m getting this error "Filtering out
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as it
isnt supported by the socket”
>

You've specified ECDHE_RSA as the cypher. This is a new-ish cypher based on
elliptic curve cryptography and it may not be available to some
distributions. Run "openssl ciphers ECDH" on the node and the client to
ensure they both support that algorithm (my guess is one or the other
won't).

This article provides an excellent description of ECDH:
https://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html#diffie-hellman-with-elliptic-curves

Unless you have a specific requirement, use "TLS_RSA_WITH_AES_256_CBC_SHA."

--
-
Nate McCall
Wellington, NZ
@zznate

CTO
Apache Cassandra Consulting
http://www.thelastpickle.com

Re: Issue in internode encryption in cassandra

[Eric Stevens]

Those ciphers are not available on Java 6, on the off chance that you're
trying to run Cassandra on that (you'll run into other troubles).

The more likely problem is that I think those ciphers are only available if
you install the Unlimited Strength JCE policy files in your JVM on each
node.  Double check that that's available universally in your cluster.

To test you can borrow this code from Atlassian:
https://confluence.atlassian.com/bitbucketserverkb/files/779171661/779171662/1/1414093373406/Ciphers.java
Run this on each machine in your cluster with
javac Ciphers.java
java Ciphers.java

Compare the output to be certain the same ciphers are available everywhere.

On Mon, Jul 25, 2016 at 4:45 AM Ashwini Mhatre (asmhatre) <
asmha...@cisco.com> wrote:

> Hi ,
>
> I am using internode encryption in cassandra, with self signed CA it works
> fine. but with other product CA m getting this error "Filtering out
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as it
> isnt supported by the socket”
>
>
> Thank you.
> Regards,
> Ashwini Mhatre
>

Issue in internode encryption in cassandra

[Ashwini Mhatre (asmhatre)]

Hi ,

I am using internode encryption in cassandra, with self signed CA it works 
fine. but with other product CA m getting this error "Filtering out 
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as it 
isnt supported by the socket”


Thank you.
Regards,
Ashwini Mhatre

Re: Encryption in cassandra

[Jack Krupansky]

Cassandra supports both client to node and inter-node security. IOW,
Cassandra can also be a client to another Cassandra node.

To repeat (and you seem to keep ignoring this) - the presumption is that
the user, outside of Cassandra, is responsible for securing the system,
including the file system, so in theory there is no way for anyone besides
a system administrator to directly access any of the actual files within
Cassandra, so there is no way for anybody to access even a clear text file.

-- Jack Krupansky

On Thu, Jan 14, 2016 at 7:32 PM, oleg yusim <olegyu...@gmail.com> wrote:

> Jack, thank you for the link, but I'm not sure what you are referring to
> by Cassandra API security. If you mean TLS connection, Cassandra
> establishing to client and between nodes, than keystore and truststore do
> not seem to participate in it at all because Cassandra is using certs and
> keys, extracted from keystore during this connection, not those which are
> stored in it (that is what made me so surprised and prompted to start this
> discussion).
>
> Now, TLS connection per say would be secure or not secure regardless of
> how you position you keys and certs. What would be important here is
> ciphers you use (and Cassandra is doing that) and ability to use CRL (I do
> not think Cassandra is doing that).
>
> Now if we are talking if positioning of certificates and keys matters for
> Cassandra as a system, than - of course it matters. Certificates and keys
> are credentials Cassandra presents during TLS, so harm is the same as
> leaving password in clear text.
>
> So, help me out here, what am I missing?
>
> Thanks,
>
> Oleg
>
> On Thu, Jan 14, 2016 at 6:10 PM, Jack Krupansky <jack.krupan...@gmail.com>
> wrote:
>
>> Cassandra is definitely assuming that you, the user, are separately
>> assuring that no intruder gets access to the box/root/login. The keystore
>> and truststore in Cassandra having nothing to do with system security, they
>> are solely for Cassandra API security.
>>
>> System security and Cassandra API security are two completely separate
>> issues. The Cassandra doc on (Cassandra, not system) security is here:
>>
>> https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/secureIntro.html
>>
>>
>>
>> -- Jack Krupansky
>>
>> On Thu, Jan 14, 2016 at 5:49 PM, oleg yusim <olegyu...@gmail.com> wrote:
>>
>>> Jack,
>>>
>>> Thanks for your answer. I guess, I'm a little confused by general
>>> architecture choice. It doesn't seem to be consistent to me. I mean, if we
>>> are building the layer of database specific security (i.e. we are saying,
>>> let's assume intruder is on the box, and he is root, what we can do?), then
>>> it is perfectly logical to build keystore and truststore, hide our keys and
>>> certificates there, encrypt the file with passwords from these stores and
>>> keep the key of the box. That is great, and as a security architect I
>>> applaud this.
>>>
>>> Now, if we are saying - no, we are banking on the fact nobody will break
>>> into the box, and if root is lost - all bets are off, that is fine too. But
>>> in this case, what is the point to even have keystore and truststore?
>>>
>>> Thanks,
>>>
>>> Oleg
>>>
>>> On Thu, Jan 14, 2016 at 4:38 PM, Jack Krupansky <
>>> jack.krupan...@gmail.com> wrote:
>>>
>>>> The point of encryption in Cassandra is to protect data in flight
>>>> between the cluster and clients (or between nodes in the cluster.) The
>>>> presumption is that normal system network access control (e.g., remote
>>>> login, etc.) will preclude bad actors from directly accessing the file
>>>> system on a cluster node.
>>>>
>>>> -- Jack Krupansky
>>>>
>>>> On Thu, Jan 14, 2016 at 5:16 PM, oleg yusim <olegyu...@gmail.com>
>>>> wrote:
>>>>
>>>>> Greetings,
>>>>>
>>>>> Guys, can you please help me to understand following:
>>>>>
>>>>> I'm reading through the way keystore and truststore are implemented,
>>>>> and it is all fine and great, but at the end Cassandra documentation
>>>>> instructing to extract all the keystore content and leave all certs and
>>>>> keys in a clear.
>>>>>
>>>>> Do I miss something here? Why are we doing it? What is the point to
>>>>> even have a keystore then? It doesn't look very secure to me...
>>>>>
>>>>> Another item - cassandra.yaml has passwords from keystore and
>>>>> truststore - clear text... what is the point to have these stores then, if
>>>>> passwords are out?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Oleg
>>>>>
>>>>
>>>>
>>>
>>
>

Encryption in cassandra

[oleg yusim]

Greetings,

Guys, can you please help me to understand following:

I'm reading through the way keystore and truststore are implemented, and it
is all fine and great, but at the end Cassandra documentation instructing
to extract all the keystore content and leave all certs and keys in a clear.

Do I miss something here? Why are we doing it? What is the point to even
have a keystore then? It doesn't look very secure to me...

Another item - cassandra.yaml has passwords from keystore and truststore -
clear text... what is the point to have these stores then, if passwords are
out?

Thanks,

Oleg

Re: Encryption in cassandra

[oleg yusim]

Jack,

Thanks for your answer. I guess, I'm a little confused by general
architecture choice. It doesn't seem to be consistent to me. I mean, if we
are building the layer of database specific security (i.e. we are saying,
let's assume intruder is on the box, and he is root, what we can do?), then
it is perfectly logical to build keystore and truststore, hide our keys and
certificates there, encrypt the file with passwords from these stores and
keep the key of the box. That is great, and as a security architect I
applaud this.

Now, if we are saying - no, we are banking on the fact nobody will break
into the box, and if root is lost - all bets are off, that is fine too. But
in this case, what is the point to even have keystore and truststore?

Thanks,

Oleg

On Thu, Jan 14, 2016 at 4:38 PM, Jack Krupansky <jack.krupan...@gmail.com>
wrote:

> The point of encryption in Cassandra is to protect data in flight between
> the cluster and clients (or between nodes in the cluster.) The presumption
> is that normal system network access control (e.g., remote login, etc.)
> will preclude bad actors from directly accessing the file system on a
> cluster node.
>
> -- Jack Krupansky
>
> On Thu, Jan 14, 2016 at 5:16 PM, oleg yusim <olegyu...@gmail.com> wrote:
>
>> Greetings,
>>
>> Guys, can you please help me to understand following:
>>
>> I'm reading through the way keystore and truststore are implemented, and
>> it is all fine and great, but at the end Cassandra documentation
>> instructing to extract all the keystore content and leave all certs and
>> keys in a clear.
>>
>> Do I miss something here? Why are we doing it? What is the point to even
>> have a keystore then? It doesn't look very secure to me...
>>
>> Another item - cassandra.yaml has passwords from keystore and truststore
>> - clear text... what is the point to have these stores then, if passwords
>> are out?
>>
>> Thanks,
>>
>> Oleg
>>
>
>

Re: Encryption in cassandra

[Jack Krupansky]

Cassandra is definitely assuming that you, the user, are separately
assuring that no intruder gets access to the box/root/login. The keystore
and truststore in Cassandra having nothing to do with system security, they
are solely for Cassandra API security.

System security and Cassandra API security are two completely separate
issues. The Cassandra doc on (Cassandra, not system) security is here:
https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/secureIntro.html



-- Jack Krupansky

On Thu, Jan 14, 2016 at 5:49 PM, oleg yusim <olegyu...@gmail.com> wrote:

> Jack,
>
> Thanks for your answer. I guess, I'm a little confused by general
> architecture choice. It doesn't seem to be consistent to me. I mean, if we
> are building the layer of database specific security (i.e. we are saying,
> let's assume intruder is on the box, and he is root, what we can do?), then
> it is perfectly logical to build keystore and truststore, hide our keys and
> certificates there, encrypt the file with passwords from these stores and
> keep the key of the box. That is great, and as a security architect I
> applaud this.
>
> Now, if we are saying - no, we are banking on the fact nobody will break
> into the box, and if root is lost - all bets are off, that is fine too. But
> in this case, what is the point to even have keystore and truststore?
>
> Thanks,
>
> Oleg
>
> On Thu, Jan 14, 2016 at 4:38 PM, Jack Krupansky <jack.krupan...@gmail.com>
> wrote:
>
>> The point of encryption in Cassandra is to protect data in flight between
>> the cluster and clients (or between nodes in the cluster.) The presumption
>> is that normal system network access control (e.g., remote login, etc.)
>> will preclude bad actors from directly accessing the file system on a
>> cluster node.
>>
>> -- Jack Krupansky
>>
>> On Thu, Jan 14, 2016 at 5:16 PM, oleg yusim <olegyu...@gmail.com> wrote:
>>
>>> Greetings,
>>>
>>> Guys, can you please help me to understand following:
>>>
>>> I'm reading through the way keystore and truststore are implemented, and
>>> it is all fine and great, but at the end Cassandra documentation
>>> instructing to extract all the keystore content and leave all certs and
>>> keys in a clear.
>>>
>>> Do I miss something here? Why are we doing it? What is the point to even
>>> have a keystore then? It doesn't look very secure to me...
>>>
>>> Another item - cassandra.yaml has passwords from keystore and truststore
>>> - clear text... what is the point to have these stores then, if passwords
>>> are out?
>>>
>>> Thanks,
>>>
>>> Oleg
>>>
>>
>>
>

Re: Encryption in cassandra

[Jack Krupansky]

The point of encryption in Cassandra is to protect data in flight between
the cluster and clients (or between nodes in the cluster.) The presumption
is that normal system network access control (e.g., remote login, etc.)
will preclude bad actors from directly accessing the file system on a
cluster node.

-- Jack Krupansky

On Thu, Jan 14, 2016 at 5:16 PM, oleg yusim <olegyu...@gmail.com> wrote:

> Greetings,
>
> Guys, can you please help me to understand following:
>
> I'm reading through the way keystore and truststore are implemented, and
> it is all fine and great, but at the end Cassandra documentation
> instructing to extract all the keystore content and leave all certs and
> keys in a clear.
>
> Do I miss something here? Why are we doing it? What is the point to even
> have a keystore then? It doesn't look very secure to me...
>
> Another item - cassandra.yaml has passwords from keystore and truststore -
> clear text... what is the point to have these stores then, if passwords are
> out?
>
> Thanks,
>
> Oleg
>

Re: Encryption in cassandra

[daemeon reiydelle]

The keys don't have to be on the box. You do need a logi/password for c*.

sent from my mobile
Daemeon C.M. Reiydelle
USA 415.501.0198
London +44.0.20.8144.9872
On Jan 14, 2016 5:16 PM, "oleg yusim"  wrote:

> Greetings,
>
> Guys, can you please help me to understand following:
>
> I'm reading through the way keystore and truststore are implemented, and
> it is all fine and great, but at the end Cassandra documentation
> instructing to extract all the keystore content and leave all certs and
> keys in a clear.
>
> Do I miss something here? Why are we doing it? What is the point to even
> have a keystore then? It doesn't look very secure to me...
>
> Another item - cassandra.yaml has passwords from keystore and truststore -
> clear text... what is the point to have these stores then, if passwords are
> out?
>
> Thanks,
>
> Oleg
>

Re: Encryption in cassandra

[oleg yusim]

Daemeon,

Can you, please, give me a bit of beef to your idea? I'm not sure I'm fully
on board here.

Thanks,

Oleg

On Thu, Jan 14, 2016 at 4:52 PM, daemeon reiydelle 
wrote:

> The keys don't have to be on the box. You do need a logi/password for c*.
>
> sent from my mobile
> Daemeon C.M. Reiydelle
> USA 415.501.0198
> London +44.0.20.8144.9872
> On Jan 14, 2016 5:16 PM, "oleg yusim"  wrote:
>
>> Greetings,
>>
>> Guys, can you please help me to understand following:
>>
>> I'm reading through the way keystore and truststore are implemented, and
>> it is all fine and great, but at the end Cassandra documentation
>> instructing to extract all the keystore content and leave all certs and
>> keys in a clear.
>>
>> Do I miss something here? Why are we doing it? What is the point to even
>> have a keystore then? It doesn't look very secure to me...
>>
>> Another item - cassandra.yaml has passwords from keystore and truststore
>> - clear text... what is the point to have these stores then, if passwords
>> are out?
>>
>> Thanks,
>>
>> Oleg
>>
>

Re: Encryption in cassandra

[oleg yusim]

Jack, thank you for the link, but I'm not sure what you are referring to by
Cassandra API security. If you mean TLS connection, Cassandra establishing
to client and between nodes, than keystore and truststore do not seem to
participate in it at all because Cassandra is using certs and keys,
extracted from keystore during this connection, not those which are stored
in it (that is what made me so surprised and prompted to start this
discussion).

Now, TLS connection per say would be secure or not secure regardless of how
you position you keys and certs. What would be important here is ciphers
you use (and Cassandra is doing that) and ability to use CRL (I do not
think Cassandra is doing that).

Now if we are talking if positioning of certificates and keys matters for
Cassandra as a system, than - of course it matters. Certificates and keys
are credentials Cassandra presents during TLS, so harm is the same as
leaving password in clear text.

So, help me out here, what am I missing?

Thanks,

Oleg

On Thu, Jan 14, 2016 at 6:10 PM, Jack Krupansky <jack.krupan...@gmail.com>
wrote:

> Cassandra is definitely assuming that you, the user, are separately
> assuring that no intruder gets access to the box/root/login. The keystore
> and truststore in Cassandra having nothing to do with system security, they
> are solely for Cassandra API security.
>
> System security and Cassandra API security are two completely separate
> issues. The Cassandra doc on (Cassandra, not system) security is here:
>
> https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/secureIntro.html
>
>
>
> -- Jack Krupansky
>
> On Thu, Jan 14, 2016 at 5:49 PM, oleg yusim <olegyu...@gmail.com> wrote:
>
>> Jack,
>>
>> Thanks for your answer. I guess, I'm a little confused by general
>> architecture choice. It doesn't seem to be consistent to me. I mean, if we
>> are building the layer of database specific security (i.e. we are saying,
>> let's assume intruder is on the box, and he is root, what we can do?), then
>> it is perfectly logical to build keystore and truststore, hide our keys and
>> certificates there, encrypt the file with passwords from these stores and
>> keep the key of the box. That is great, and as a security architect I
>> applaud this.
>>
>> Now, if we are saying - no, we are banking on the fact nobody will break
>> into the box, and if root is lost - all bets are off, that is fine too. But
>> in this case, what is the point to even have keystore and truststore?
>>
>> Thanks,
>>
>> Oleg
>>
>> On Thu, Jan 14, 2016 at 4:38 PM, Jack Krupansky <jack.krupan...@gmail.com
>> > wrote:
>>
>>> The point of encryption in Cassandra is to protect data in flight
>>> between the cluster and clients (or between nodes in the cluster.) The
>>> presumption is that normal system network access control (e.g., remote
>>> login, etc.) will preclude bad actors from directly accessing the file
>>> system on a cluster node.
>>>
>>> -- Jack Krupansky
>>>
>>> On Thu, Jan 14, 2016 at 5:16 PM, oleg yusim <olegyu...@gmail.com> wrote:
>>>
>>>> Greetings,
>>>>
>>>> Guys, can you please help me to understand following:
>>>>
>>>> I'm reading through the way keystore and truststore are implemented,
>>>> and it is all fine and great, but at the end Cassandra documentation
>>>> instructing to extract all the keystore content and leave all certs and
>>>> keys in a clear.
>>>>
>>>> Do I miss something here? Why are we doing it? What is the point to
>>>> even have a keystore then? It doesn't look very secure to me...
>>>>
>>>> Another item - cassandra.yaml has passwords from keystore and
>>>> truststore - clear text... what is the point to have these stores then, if
>>>> passwords are out?
>>>>
>>>> Thanks,
>>>>
>>>> Oleg
>>>>
>>>
>>>
>>
>

Re: sstableloader does not support client encryption on Cassandra 2.0?

[Tyler Hobbs]

I think this is just an oversight; would you mind opening a ticket here?
https://issues.apache.org/jira/browse/CASSANDRA


On Mon, Nov 18, 2013 at 12:37 PM, David Laube d...@stormpath.com wrote:

 Hi All,

 We have been testing backup/restore from one ring to another and we
 recently stumbled upon an issue with sstableloader. When client_enc_enable:
 true, the exception below is generated. When client_enc_enable is set to
 false, the sstableloader is able to get to the point where it is discovers
 endpoints, connects to stream data, etc.

 ==BEGIN EXCEPTION==
  sstableloader --debug -d x.x.x.248,x.x.x.108,x.x.x.113
 /tmp/import/keyspace_name/columnfamily_name
 Exception in thread main java.lang.RuntimeException: Could not retrieve
 endpoint ranges:
 at
 org.apache.cassandra.tools.BulkLoader$ExternalClient.init(BulkLoader.java:226)
 at
 org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:149)
 at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:68)
 Caused by: org.apache.thrift.transport.TTransportException: Frame size
 (352518400) larger than max length (16384000)!
 at
 org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTransport.java:137)
 at
 org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.java:101)
 at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
 at
 org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:362)
 at
 org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:284)
 at
 org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:191)
 at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:69)
 at
 org.apache.cassandra.thrift.Cassandra$Client.recv_describe_partitioner(Cassandra.java:1292)
 at
 org.apache.cassandra.thrift.Cassandra$Client.describe_partitioner(Cassandra.java:1280)
 at
 org.apache.cassandra.tools.BulkLoader$ExternalClient.init(BulkLoader.java:199)
 ... 2 more
 ==END EXCEPTION==


 Has anyone seen this before or can someone confirm that SSL/encryption is
 not supported under the open source project and only with d-stax enterprise?

 Thanks,
 -David Laube




-- 
Tyler Hobbs
DataStax http://datastax.com/

Re: sstableloader does not support client encryption on Cassandra 2.0?

[David Laube]

Thank you Tyler. I took your advice and I have opened 
https://issues.apache.org/jira/browse/CASSANDRA-6378

Best regards,
-David Laube

On Nov 19, 2013, at 9:51 AM, Tyler Hobbs ty...@datastax.com wrote:

 I think this is just an oversight; would you mind opening a ticket here? 
 https://issues.apache.org/jira/browse/CASSANDRA
 
 
 On Mon, Nov 18, 2013 at 12:37 PM, David Laube d...@stormpath.com wrote:
 Hi All,
 
 We have been testing backup/restore from one ring to another and we recently 
 stumbled upon an issue with sstableloader. When client_enc_enable: true, the 
 exception below is generated. When client_enc_enable is set to false, the 
 sstableloader is able to get to the point where it is discovers endpoints, 
 connects to stream data, etc.
 
 ==BEGIN EXCEPTION==
  sstableloader --debug -d x.x.x.248,x.x.x.108,x.x.x.113 
 /tmp/import/keyspace_name/columnfamily_name
 Exception in thread main java.lang.RuntimeException: Could not retrieve 
 endpoint ranges:
 at 
 org.apache.cassandra.tools.BulkLoader$ExternalClient.init(BulkLoader.java:226)
 at 
 org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:149)
 at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:68)
 Caused by: org.apache.thrift.transport.TTransportException: Frame size 
 (352518400) larger than max length (16384000)!
 at 
 org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTransport.java:137)
 at 
 org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.java:101)
 at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
 at 
 org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:362)
 at 
 org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:284)
 at 
 org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:191)
 at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:69)
 at 
 org.apache.cassandra.thrift.Cassandra$Client.recv_describe_partitioner(Cassandra.java:1292)
 at 
 org.apache.cassandra.thrift.Cassandra$Client.describe_partitioner(Cassandra.java:1280)
 at 
 org.apache.cassandra.tools.BulkLoader$ExternalClient.init(BulkLoader.java:199)
 ... 2 more
 ==END EXCEPTION==
 
 
 Has anyone seen this before or can someone confirm that SSL/encryption is not 
 supported under the open source project and only with d-stax enterprise?
 
 Thanks,
 -David Laube
 
 
 
 -- 
 Tyler Hobbs
 DataStax

sstableloader does not support client encryption on Cassandra 2.0?

[David Laube]

Hi All,

We have been testing backup/restore from one ring to another and we recently 
stumbled upon an issue with sstableloader. When client_enc_enable: true, the 
exception below is generated. When client_enc_enable is set to false, the 
sstableloader is able to get to the point where it is discovers endpoints, 
connects to stream data, etc.

==BEGIN EXCEPTION==
 sstableloader --debug -d x.x.x.248,x.x.x.108,x.x.x.113 
/tmp/import/keyspace_name/columnfamily_name
Exception in thread main java.lang.RuntimeException: Could not retrieve 
endpoint ranges:
at 
org.apache.cassandra.tools.BulkLoader$ExternalClient.init(BulkLoader.java:226)
at org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:149)
at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:68)
Caused by: org.apache.thrift.transport.TTransportException: Frame size 
(352518400) larger than max length (16384000)!
at 
org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTransport.java:137)
at org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.java:101)
at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
at org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:362)
at org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:284)
at 
org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:191)
at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:69)
at 
org.apache.cassandra.thrift.Cassandra$Client.recv_describe_partitioner(Cassandra.java:1292)
at 
org.apache.cassandra.thrift.Cassandra$Client.describe_partitioner(Cassandra.java:1280)
at 
org.apache.cassandra.tools.BulkLoader$ExternalClient.init(BulkLoader.java:199)
... 2 more
==END EXCEPTION==


Has anyone seen this before or can someone confirm that SSL/encryption is not 
supported under the open source project and only with d-stax enterprise?

Thanks,
-David Laube