ussion. I started reading this thread and still
> have to catch-up a lot but based on my experience many big organizations
> ultimately settle on having over-the-wire encryption combined with OS/disk
> encryption to comply with the security requirements for various reasons
> like,
>
Hi all
Really interesting discussion. I started reading this thread and still have
to catch-up a lot but based on my experience many big organizations
ultimately settle on having over-the-wire encryption combined with OS/disk
encryption to comply with the security requirements for various reasons
9, 2021 4:53 AM
To: dev@cassandra.apache.org
Subject: Re: Resurrection of CASSANDRA-9633 - SSTable encryption
>
> setting performance requirements on this regard is a nonsense. As long
> as it's reasonably usable in real world, and Cassandra makes the
> estimated effects on perf
Thanks, that's really helpful to have some code to look at!
Derek
On Fri, Nov 19, 2021 at 9:35 AM Joseph Lynch wrote:
> On Fri, Nov 19, 2021 at 9:52 AM Derek Chen-Becker
> wrote:
> >
> > https://bugs.openjdk.java.net/browse/JDK-7184394 added AES intrinsics in
> > Java 8, in 2012. While it's al
On Fri, Nov 19, 2021 at 9:52 AM Derek Chen-Becker wrote:
>
> https://bugs.openjdk.java.net/browse/JDK-7184394 added AES intrinsics in
> Java 8, in 2012. While it's always possible to have a regression, and it's
> important to understand the performance impact, stories of 2-10x sound
> apocryphal.
> On Nov 19, 2021, at 2:53 PM, Joseph Lynch wrote:
>
>
>>
>> For better or worse, different threat models mean that it’s not strictly
>> better to do FDE and some use cases definitely want this at the db layer
>> instead of file system.
>
> Do you mind elaborating which threat models? Th
> For better or worse, different threat models mean that it’s not strictly
> better to do FDE and some use cases definitely want this at the db layer
> instead of file system.
Do you mind elaborating which threat models? The only one I can think
of is users can log onto the database machine and
better to do FDE and some use cases definitely want this at the db layer
> instead of file system.
> >
> >> On Nov 19, 2021, at 12:54 PM, Joshua McKenzie
> wrote:
> >>
> >>
> >>>
> >>> setting performance requirements on this regar
> I think Joey's argument, and correct me if I'm wrong, is that implementing
> a complex feature in Cassandra that we then have to manage that's
> essentially worse in every way compared to a built-in full-disk encryption
> option via LUKS+LVM etc is a poor use of o
>
> Yes, this needs to be done. The credentials for this stuff should be
> just fetched from wherever one wants. 100% agree with that and that
> maybe next iteration on top of that, should be rather easy. This was
> done in CEP-9 already for SSL context creation so we would just copy
> that approac
rators to decide whether to turn on the feature
I think Joey's argument, and correct me if I'm wrong, is that implementing
a complex feature in Cassandra that we then have to manage that's
essentially worse in every way compared to a built-in full-disk encryption
option via LUKS+L
performance
penalty I think it's important to document how/if we are worse (we might
not be).
I don't actually think the 1% number is important, and I certainly don't
think we give any kind of guarantee, I'm just trying to say that if we
invest in encryption of the storage en
gument, and correct me if I'm wrong, is that implementing
> a complex feature in Cassandra that we then have to manage that's
> essentially worse in every way compared to a built-in full-disk encryption
> option via LUKS+LVM etc is a poor use of our time and energy.
>
> i.e. w
Joey's argument, and correct me if I'm wrong, is that implementing
a complex feature in Cassandra that we then have to manage that's
essentially worse in every way compared to a built-in full-disk encryption
option via LUKS+LVM etc is a poor use of our time and energy.
i.e. we'
kes advantage of hardware instructions.
From our internal experiments, we see single digit % regression when
transparent data encryption is enabled.
Which workloads are you testing and how are you measuring the regression? I
suspect that compaction, repair (validation compaction), streaming, and
quoru
mportant feature, but in the six
> years since the ticket was originally proposed other systems kept getting
> better at a faster rate, especially easy to use full disk and filesystem
> encryption. LUKS+LVM in Linux is genuinely excellent and is relatively easy
> to setup today while that was
costs or the JNI barrier (in the case of ACCP) and
> the kernel also takes advantage of hardware instructions.
>
>
> > From our internal experiments, we see single digit % regression when
> > transparent data encryption is enabled.
> >
>
> Which workloads are you testing and
ter at a faster rate, especially easy to use full disk and filesystem
encryption. LUKS+LVM in Linux is genuinely excellent and is relatively easy
to setup today while that was _not_ true five years ago.
> That said, I completely agree that we don't want to be engaging in security
>
e digit % regression when
> transparent data encryption is enabled.
>
Which workloads are you testing and how are you measuring the regression? I
suspect that compaction, repair (validation compaction), streaming, and
quorum reads are probably much slower (probably ~10x slower for the
thro
Intel platform is utilized
by the JVM while running on that platform to make crypto operations faster.
>From our internal experiments, we see single digit % regression when
>transparent data encryption is enabled.
-Original Message-
From: bened...@apache.org
Sent: Thursday, November 18
I agree with Joey that most users may be better served by OS level encryption,
but I also think this ticket can likely be delivered fairly easily. If we have
a new contributor willing to produce a patch then the overhead for the project
in shepherding it shouldn’t be that onerous. If we also
I wanted to provide a bit of background in the interest we've seen in this
ticket/feature (at Instaclustr) - essentially it comes down to in-db
encryption at rest being a feature that compliance people are used to
seeing in databases and having a very hard time believing that operating
s
For FDE you'd probably have the key file in a tmpfs pulled from a
remote secret manager and when the machine boots it mounts the
encrypted partition that contains your data files. I'm not aware of
anyone doing FDE with a password in production. If you wanted
selective encryption it
I don't like the idea that FDE Full Disk Encryption as an alternative to
application managed encryption at rest. Each has their own advantages
and disadvantages.
For example, if the encryption key is the same across nodes in the same
cluster, and Cassandra can share the key securely be
On Tue, 16 Nov 2021 at 16:17, Joseph Lynch wrote:
>
> > I find it rather strange to offer commit log and hints
> encryption at rest but for some reason sstable encryption would be
> omitted.
>
> I also think file/disk encryption may be superior in those cases
Just for the
> I find it rather strange to offer commit log and hints
encryption at rest but for some reason sstable encryption would be
omitted.
I also think file/disk encryption may be superior in those cases, but
I imagine they were easier to implement in that you don't have to
worry nearly as mu
I don't object to having the discussion about whether we actually need
this feature at all :)
Let's hear from people in the field what their perception is on this.
Btw, if we should rely on file system encryption, for what reason is
there encryption of commit logs and hints alread
I think a CEP is wise (or a more thorough design document on the
ticket) given how easy it is to do security incorrectly and key
management, rotation and key derivation are not particularly
straightforward.
I am curious what advantage Cassandra implementing encryption has over
asking the user to
eply when I got that right.
On Tue, 16 Nov 2021 at 13:02, bened...@apache.org wrote:
We already have the facility to authenticate peers, I am suggesting we should
e.g. refuse to enable encryption if there is no such facility configured for a
replica, or fail to start if there is encrypted
I got that right.
> >
> > On Tue, 16 Nov 2021 at 13:02, bened...@apache.org
> > wrote:
> >> We already have the facility to authenticate peers, I am suggesting we
> >> should e.g. refuse to enable encryption if there is no such facility
> >> config
should
e.g. refuse to enable encryption if there is no such facility configured for a
replica, or fail to start if there is encrypted data present and no
authentication facility configured.
It is in my opinion much more problematic to remove encryption from data and
ship it to another node in
I’m not suggesting enforcing network encryption, just prohibiting
unauthenticated connections from peers so that we do not effectively offer a
decrypt-all-the-data endpoint.
If as an operator you know that it is impossible for unauthenticated peers to
open a connection due to your network
I think a warning message is fine, but Cassandra should not enforce
network encryption when on-disk encryption is enabled. It's definitely a
valid use case to have Cassandra over IPSec without enabling TLS.
On 16/11/2021 12:02, bened...@apache.org wrote:
We already have the facili
v 2021 at 13:02, bened...@apache.org wrote:
>
> We already have the facility to authenticate peers, I am suggesting we should
> e.g. refuse to enable encryption if there is no such facility configured for
> a replica, or fail to start if there is encrypted data present and no
> auth
We already have the facility to authenticate peers, I am suggesting we should
e.g. refuse to enable encryption if there is no such facility configured for a
replica, or fail to start if there is encrypted data present and no
authentication facility configured.
It is in my opinion much more
general problem not specific to the on-disk encryption.
On 16/11/2021 10:50, bened...@apache.org wrote:
I assume the key would be decrypted before being streamed, or perhaps encrypted
using a public key provided to you by the receiving node. This would permit
efficient “zero copy” streaming for the
No, the Km does not need to be the same across nodes. Each node can
store their own encryption info file created by their own Km. The
streaming process only requires the Kr is shared.
A quick description of the streaming process via an insecure connection:
1. the sender unwrap the wrapped key
: Re: Resurrection of CASSANDRA-9633 - SSTable encryption
Ok but this also means that Km would need to be the same for all nodes right?
If we are rolling in node by node fashion, Km is changed at node 1, we
change the wrapped key which is stored on disk and we stream this
table to the other node
rest applications. One good example is the
> LUKS full disk encryption, which also supports multiple keys to unlock
> (decrypt) the same data. Multiple unlocking keys is only possible
> because the actual key used to encrypt the data is randomly generated
> and then stored encrypted b
Yes, that's correct. The actual key used to encrypt the SSTable will
stay the same once the SSTable is created. This is a widely used
practice in many encrypt-at-rest applications. One good example is the
LUKS full disk encryption, which also supports multiple keys to unlock
(decrypt) the
, Stefan Miklosovic
wrote:
>
> Hi Bowen, Very interesting idea indeed. So if I got it right, the very
> key for the actual sstable encryption would be always the same, it is
> just what is wrapped would differ. So if we rotate, we basically only
> change Km hence KEK hence the res
Hi Bowen, Very interesting idea indeed. So if I got it right, the very
key for the actual sstable encryption would be always the same, it is
just what is wrapped would differ. So if we rotate, we basically only
change Km hence KEK hence the result of wrapping but there would still
be the original
;
> Hey,
>
> there are two points we are not completely sure about.
>
> The first one is streaming. If there is a cluster of 5 nodes, each
> node has its own unique encryption key. Hence, if a SSTable is stored
> on a disk with the key for node 1 and this is streamed to node 2 -
&g
operator could then trigger a “nodetool
upgradesstables —all” to rewrite the existing sstables with the new “current
key”.
There's a much better approach to solve this issue. You can stored a
wrapped key in an encryption info file alone side the SSTable file.
Here's how it works:
1
If decrypting before transmission we’ll want to require the cluster to have an
internode authenticator setup, else a nefarious process could simply ask for
data to be streamed to it to circumvent the encryption.
I agree it would be nice to have the nodes share the secret some way to avoid
the
e:
>>>
>>> Hey,
>>>
>>> there are two points we are not completely sure about.
>>>
>>> The first one is streaming. If there is a cluster of 5 nodes, each
>>> node has its own unique encryption key. Hence, if a SSTable is stored
>>> o
there is a cluster of 5 nodes, each
> > node has its own unique encryption key. Hence, if a SSTable is stored
> > on a disk with the key for node 1 and this is streamed to node 2 -
> > which has a different key - it would not be able to decrypt that. Our
> > idea is to act
> On Nov 14, 2021, at 3:53 PM, Stefan Miklosovic
> wrote:
>
> Hey,
>
> there are two points we are not completely sure about.
>
> The first one is streaming. If there is a cluster of 5 nodes, each
> node has its own unique encryption key. Hence, if a SSTable is
Hey,
there are two points we are not completely sure about.
The first one is streaming. If there is a cluster of 5 nodes, each
node has its own unique encryption key. Hence, if a SSTable is stored
on a disk with the key for node 1 and this is streamed to node 2 -
which has a different key - it
. I see that the 2016 version adds
a couple round-trip unit tests with a small amount of static data. It would be
good to see randomized tests fleshed out that exercise more of the read/write
path; or which add variants of existing read/write path tests that enable
encryption.
– Scott
> On
We already have a ticket and this predated CEPs, and being an
obviously good improvement to have that many have been asking for for
some time now, I don't see the need for a CEP here.
On Sat, Nov 13, 2021 at 5:01 AM Stefan Miklosovic
wrote:
>
> Hi list,
>
> an engineer from Intel - Shylaja Kokoor
Hi list,
an engineer from Intel - Shylaja Kokoori (who is watching this list
closely) has retrofitted the original code from CASSANDRA-9633 work in
times of 3.4 to the current trunk with my help here and there, mostly
cosmetic.
I would like to know if there is a general consensus about me going t
Correction: 3.11.x users should upgrade to 3.11.10. 3.11.24 doesn’t exist. Yet.
> On 1 Feb 2021, at 18:22, Aleksey Yeschenko wrote:
>
> CVE-2020-17516: Apache Cassandra doesn't enforce encryption setting on
> inbound internode connections
>
> Severity:
> Important
CVE-2020-17516: Apache Cassandra doesn't enforce encryption setting on inbound
internode connections
Severity:
Important
Vendor:
The Apache Software Foundation
Versions Affected:
Cassandra 2.1.0 to 2.1.22
Cassandra 2.2.0 to 2.2.19
Cassandra 3.0.0 to 3.0.23
Cassandra 3.11.0 to 3
Just some housekeeping paper work for export controls per:
http://www.apache.org/licenses/exports/
See https://issues.apache.org/jira/browse/CASSANDRA-14634 and
https://issues.apache.org/jira/browse/LEGAL-358 if you're curios.
On Tue, Sep 25, 2018 at 5:28 PM Nate McCall wrote:
>
> SUBMISSION TYPE
SUBMISSION TYPE: TSU
SUBMITTED BY: Nate McCall
SUBMITTED FOR:The Apache Software Foundation
POINT OF CONTACT: Secretary, The Apache Software Foundation
FAX: +1-919-573-9199
MANUFACTURER(S): The Apache Software Foundation, Oracle, The
OpenSSL Proje
at 2:24 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
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
Greetings,
I'm looking at the data-at-transit encryption implementation from the
security point of view, and I'm mildly surprised with following:
1) Passwords for keystore and truststore are in clear text in
cassandra.yaml (Why? If we are going into the trouble of creating ke
to setup internode and client encryption on cassandra. I set
> up a small ca, generated the certificates, distributed them and configured
> the nodes to use them.
>
> Internode encryption worked straight forward, cqlsh after I added "--ssl".
>
> But I am not able to setup
Hi all,
I am trying to setup internode and client encryption on cassandra. I set
up a small ca, generated the certificates, distributed them and
configured the nodes to use them.
Internode encryption worked straight forward, cqlsh after I added "--ssl".
But I am not able to setup
61 matches
Mail list logo
