You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by "Jason J. W. Williams" <ja...@gmail.com> on 2016/04/20 00:31:56 UTC
Optional TLS CQL Encryption
Hey Guys,
Is there a way to make TLS encryption optional for the CQL listener? We'd
like to be able to use for remote management connections but not for same
datacenter usage (since the build/up tear down cost is too high for things
that don't use pools).
Right now it appears if we enable encryption it requires it for all
connections, which definitely is not what we want.
-J
Re: Optional TLS CQL Encryption
Posted by Jason Williams <ja...@gmail.com>.
Hi Sam,
That's exactly what I was hoping for, but couldn't find in the docs. Thank you very much!
-J
Sent via iPhone
> On Apr 20, 2016, at 02:05, Sam Tunnicliffe <sa...@beobal.com> wrote:
>
> From 3.0, separate ports can be configured for encrypted & non-encrypted connections.
> See https://issues.apache.org/jira/browse/CASSANDRA-9590
>
>> On Wed, Apr 20, 2016 at 8:51 AM, Jason J. W. Williams <ja...@gmail.com> wrote:
>> Hi Ben,
>>
>> Thanks for confirming what I saw occur. The Datastax drivers don't play very nicely with Twisted Python so connection pooling is inconsistent and makes always-on TLS a no-go performance-wise. The encryption overhead isn't the problem, it's the build-up of the TLS session for every connection when connection pooling is not working as needed. That said it is still beneficial to be able to enforce TLS for remote access...MySQL allows you to enforce TLS on a per-user basis for example.
>>
>> If someone has been successful not wrapping the Datastax drivers in deferToThread calls when using Twisted I'd appreciate insight on how you got that working because its pretty much undocumented.
>>
>> -J
>>
>>> On Tue, Apr 19, 2016 at 11:46 PM, Ben Bromhead <be...@instaclustr.com> wrote:
>>> Hi Jason
>>>
>>> If you enable encryption it will be always on. Optional encryption is generally a bad idea (tm). Also always creating a new session every query is also a bad idea (tm) even without the minimal overhead of encryption.
>>>
>>> If you are really hell bent on doing this you could have a node that is part of the cluster but has -Dcassandra.join_ring=false set in jvm options in cassandra-env.sh so it does not get any data and configure that to have no encryption enabled. This is known as a fat client. Then connect to that specific node whenever you want to do terrible non encrypted things.
>>>
>>> Having said all that, please don't do this.
>>>
>>> Cheers
>>>
>>>> On Tue, 19 Apr 2016 at 15:32 Jason J. W. Williams <ja...@gmail.com> wrote:
>>>> Hey Guys,
>>>>
>>>> Is there a way to make TLS encryption optional for the CQL listener? We'd like to be able to use for remote management connections but not for same datacenter usage (since the build/up tear down cost is too high for things that don't use pools).
>>>>
>>>> Right now it appears if we enable encryption it requires it for all connections, which definitely is not what we want.
>>>>
>>>> -J
>>>
>>> --
>>> Ben Bromhead
>>> CTO | Instaclustr
>>> +1 650 284 9692
>>> Managed Cassandra / Spark on AWS, Azure and Softlayer
>
Re: Optional TLS CQL Encryption
Posted by Sam Tunnicliffe <sa...@beobal.com>.
>From 3.0, separate ports can be configured for encrypted & non-encrypted
connections.
See https://issues.apache.org/jira/browse/CASSANDRA-9590
On Wed, Apr 20, 2016 at 8:51 AM, Jason J. W. Williams <
jasonjwwilliams@gmail.com> wrote:
> Hi Ben,
>
> Thanks for confirming what I saw occur. The Datastax drivers don't play
> very nicely with Twisted Python so connection pooling is inconsistent and
> makes always-on TLS a no-go performance-wise. The encryption overhead isn't
> the problem, it's the build-up of the TLS session for every connection when
> connection pooling is not working as needed. That said it is still
> beneficial to be able to enforce TLS for remote access...MySQL allows you
> to enforce TLS on a per-user basis for example.
>
> If someone has been successful not wrapping the Datastax drivers in
> deferToThread calls when using Twisted I'd appreciate insight on how you
> got that working because its pretty much undocumented.
>
> -J
>
> On Tue, Apr 19, 2016 at 11:46 PM, Ben Bromhead <be...@instaclustr.com>
> wrote:
>
>> Hi Jason
>>
>> If you enable encryption it will be always on. Optional encryption is
>> generally a bad idea (tm). Also always creating a new session every query
>> is also a bad idea (tm) even without the minimal overhead of encryption.
>>
>> If you are really hell bent on doing this you could have a node that is
>> part of the cluster but has -Dcassandra.join_ring=false set in jvm
>> options in cassandra-env.sh so it does not get any data and configure
>> that to have no encryption enabled. This is known as a fat client. Then
>> connect to that specific node whenever you want to do terrible non
>> encrypted things.
>>
>> Having said all that, please don't do this.
>>
>> Cheers
>>
>> On Tue, 19 Apr 2016 at 15:32 Jason J. W. Williams <
>> jasonjwwilliams@gmail.com> wrote:
>>
>>> Hey Guys,
>>>
>>> Is there a way to make TLS encryption optional for the CQL listener?
>>> We'd like to be able to use for remote management connections but not for
>>> same datacenter usage (since the build/up tear down cost is too high for
>>> things that don't use pools).
>>>
>>> Right now it appears if we enable encryption it requires it for all
>>> connections, which definitely is not what we want.
>>>
>>> -J
>>>
>> --
>> Ben Bromhead
>> CTO | Instaclustr <https://www.instaclustr.com/>
>> +1 650 284 9692
>> Managed Cassandra / Spark on AWS, Azure and Softlayer
>>
>
>
Re: Optional TLS CQL Encryption
Posted by "Jason J. W. Williams" <ja...@gmail.com>.
Hi Ben,
Thanks for confirming what I saw occur. The Datastax drivers don't play
very nicely with Twisted Python so connection pooling is inconsistent and
makes always-on TLS a no-go performance-wise. The encryption overhead isn't
the problem, it's the build-up of the TLS session for every connection when
connection pooling is not working as needed. That said it is still
beneficial to be able to enforce TLS for remote access...MySQL allows you
to enforce TLS on a per-user basis for example.
If someone has been successful not wrapping the Datastax drivers in
deferToThread calls when using Twisted I'd appreciate insight on how you
got that working because its pretty much undocumented.
-J
On Tue, Apr 19, 2016 at 11:46 PM, Ben Bromhead <be...@instaclustr.com> wrote:
> Hi Jason
>
> If you enable encryption it will be always on. Optional encryption is
> generally a bad idea (tm). Also always creating a new session every query
> is also a bad idea (tm) even without the minimal overhead of encryption.
>
> If you are really hell bent on doing this you could have a node that is
> part of the cluster but has -Dcassandra.join_ring=false set in jvm
> options in cassandra-env.sh so it does not get any data and configure
> that to have no encryption enabled. This is known as a fat client. Then
> connect to that specific node whenever you want to do terrible non
> encrypted things.
>
> Having said all that, please don't do this.
>
> Cheers
>
> On Tue, 19 Apr 2016 at 15:32 Jason J. W. Williams <
> jasonjwwilliams@gmail.com> wrote:
>
>> Hey Guys,
>>
>> Is there a way to make TLS encryption optional for the CQL listener? We'd
>> like to be able to use for remote management connections but not for same
>> datacenter usage (since the build/up tear down cost is too high for things
>> that don't use pools).
>>
>> Right now it appears if we enable encryption it requires it for all
>> connections, which definitely is not what we want.
>>
>> -J
>>
> --
> Ben Bromhead
> CTO | Instaclustr <https://www.instaclustr.com/>
> +1 650 284 9692
> Managed Cassandra / Spark on AWS, Azure and Softlayer
>
Re: Optional TLS CQL Encryption
Posted by Ben Bromhead <be...@instaclustr.com>.
Hi Jason
If you enable encryption it will be always on. Optional encryption is
generally a bad idea (tm). Also always creating a new session every query
is also a bad idea (tm) even without the minimal overhead of encryption.
If you are really hell bent on doing this you could have a node that is
part of the cluster but has -Dcassandra.join_ring=false set in jvm options
in cassandra-env.sh so it does not get any data and configure that to have
no encryption enabled. This is known as a fat client. Then connect to that
specific node whenever you want to do terrible non encrypted things.
Having said all that, please don't do this.
Cheers
On Tue, 19 Apr 2016 at 15:32 Jason J. W. Williams <ja...@gmail.com>
wrote:
> Hey Guys,
>
> Is there a way to make TLS encryption optional for the CQL listener? We'd
> like to be able to use for remote management connections but not for same
> datacenter usage (since the build/up tear down cost is too high for things
> that don't use pools).
>
> Right now it appears if we enable encryption it requires it for all
> connections, which definitely is not what we want.
>
> -J
>
--
Ben Bromhead
CTO | Instaclustr <https://www.instaclustr.com/>
+1 650 284 9692
Managed Cassandra / Spark on AWS, Azure and Softlayer