Re: Optional TLS CQL Encryption

[Jason Williams]

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  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 
>>  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  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 
  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

[Sam Tunnicliffe]

>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 <
jasonjwwilli...@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 
> 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 <
>> jasonjwwilli...@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

[Jason J. W. Williams]

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  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 <
> jasonjwwilli...@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

[Ben Bromhead]

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 
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