Re: Does Open-Source Cassandra 4 support mutual-TLS ?

[Dinesh Joshi]

> On Sep 22, 2021, at 8:03 AM, Bowen Song  wrote:
> 
> Interesting. The better approach is to match the certificate's common name or 
> SAN to the CQL username. This way the authorisation part, which depends on 
> the CQL username, will continue to work as usual.
> 
Yes, that is one way of deriving an identity. The other "standard" mechanism is 
to use spiffe ids[1] to encode an identity and to derive your 
username/principal from it.

Dinesh

[1] 
https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md#2-spiffe-id

> On 22/09/2021 15:40, Dinesh Joshi wrote:
>>> On Sep 22, 2021, at 2:02 AM, Bowen Song >> > wrote:
>>> Out of curiosity, I have two further questions.
>>> 
>>> 1. I know the client can optionally provider a certificate for the TLS 
>>> handshake, but is it possible to require the client to provide a 
>>> certificate?
>>> 
>> 
>> Yep, you can turn on require_client_auth under the client_encyrption_options 
>> in Cassandra YAML to 
>> https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L1160 
>>  
>> This requires the CQL client to provide client certificates.
>> 
>>> 2. Does Cassandra check that the username matches the client certificate? 
>>> E.g. TLS client certificate is issued to "bob", but logging in CQL using 
>>> the username "charol".
>>> 
>> no. The client certificates that you provide should be trusted by the 
>> server's truststore for the connection to succeed. Thats it. AFAIK there 
>> isn't an accepted secure standard to encode a "username" inside a TLS client 
>> certificate that we can use to derive a principal. 
>>> If the answer to Q2 is "no", it would mean that the TLS client certificate 
>>> is used for primary authentication (but not authorisation), and the CQL 
>>> username & password will be used for secondary authentication and 
>>> authorisation. Anyone who has a valid client certificate and private key 
>>> pair can impersonate any CQL user if they know the username and password. 
>>> Depending on the threat model, this may or may not pose a security risk.
>>> 
>> The client certificate can be used to ensure that it is a trusted client. If 
>> a bad actor is able to not only obtain a valid client certificate but also 
>> the private key pair then you have bigger issues :)
>> 
>> In 4.0 the IAuthenticator interface has changed slightly to pass down the 
>> client certificates that the server receives. In theory one can create an 
>> implementation of this interface that can derive an identity from the client 
>> certificates and then use that to perform authentication. This would give 
>> you what you're looking for. If you'd like, you can go as far as ignoring 
>> the username/password passed down from the cilent and only rely on the 
>> identity encoded in the certificate as your source of truth.
>> 
>> Dinesh
>>> 
>>> On 21/09/2021 23:16, Dinesh Joshi wrote:
 It sort of supports it. You still need to send in the username/password 
 credentials along with the client certificate to authenticate. Cassandra 
 will not derive the identity purely from the client certificate.
 
 Dinesh
 
> On Sep 21, 2021, at 11:59 AM, S G  
>  wrote:
> 
> Hello,
> 
> Does anyone know if opensource Cassandra support mutual-TLS ?
> The documentation doesn't conclusively deny or accept the support for the 
> same.
> 
> Thanks !
>> 

Re: Does Open-Source Cassandra 4 support mutual-TLS ?

[Bowen Song]

Hello Dinesh,


/> The client certificate can be used to ensure that it is a trusted 
client. If a bad actor is able to not only obtain a valid client 
certificate but also the private key pair then you have bigger issues :)/


Not really. As I said, it depends on the threat model. For example, if 
the server allows guest users to have readonly access, the server must 
accept their client certificate. However, if a malicious guest user 
managed to get their hand on a CQL credential with write permission 
(social engineering, brute force, ...), they will be able to use their 
client certificate and the hacked CQL credential to make changes to the 
database. After all, it's much easier to steal a password than a 
certificate & private key pair (potentially stored on hardware).


/> In 4.0 the IAuthenticator interface has changed slightly to pass down 
the client certificates that the server receives. In theory one can 
create an implementation of this interface that can derive an identity 
from the client certificates and then use that to perform 
authentication. This would give you what you're looking for. If you'd 
like, you can go as far as ignoring the username/password passed down 
from the cilent and only rely on the identity encoded in the certificate 
as your source of truth./


Interesting. The better approach is to match the certificate's common 
name or SAN to the CQL username. This way the authorisation part, which 
depends on the CQL username, will continue to work as usual.


Cheers,
Bowen

On 22/09/2021 15:40, Dinesh Joshi wrote:

On Sep 22, 2021, at 2:02 AM, Bowen Song  wrote:

Out of curiosity, I have two further questions.

1. I know the client can *optionally* provider a certificate for the 
TLS handshake, but is it possible to *require* the client to provide 
a certificate?




Yep, you can turn on require_client_auth under the 
client_encyrption_options in Cassandra YAML to 
https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L1160 This 
requires the CQL client to provide client certificates.


2. Does Cassandra check that the username matches the client 
certificate? E.g. TLS client certificate is issued to "bob", but 
logging in CQL using the username "charol".


no. The client certificates that you provide should be trusted by the 
server's truststore for the connection to succeed. Thats it. AFAIK 
there isn't an accepted secure standard to encode a "username" inside 
a TLS client certificate that we can use to derive a principal.


If the answer to Q2 is "no", it would mean that the TLS client 
certificate is used for primary authentication (but not 
authorisation), and the CQL username & password will be used for 
secondary authentication and authorisation. Anyone who has a valid 
client certificate and private key pair can impersonate any CQL user 
if they know the username and password. Depending on the threat 
model, this may or may not pose a security risk.


The client certificate can be used to ensure that it is a trusted 
client. If a bad actor is able to not only obtain a valid client 
certificate but also the private key pair then you have bigger issues :)


In 4.0 the IAuthenticator interface has changed slightly to pass down 
the client certificates that the server receives. In theory one can 
create an implementation of this interface that can derive an identity 
from the client certificates and then use that to perform 
authentication. This would give you what you're looking for. If you'd 
like, you can go as far as ignoring the username/password passed down 
from the cilent and only rely on the identity encoded in the 
certificate as your source of truth.


Dinesh



On 21/09/2021 23:16, Dinesh Joshi wrote:

It sort of supports it. You still need to send in the username/password 
credentials along with the client certificate to authenticate. Cassandra will 
not derive the identity purely from the client certificate.

Dinesh


On Sep 21, 2021, at 11:59 AM, S G  wrote:

Hello,

Does anyone know if opensource Cassandra support mutual-TLS ?
The documentation doesn't conclusively deny or accept the support for the same.

Thanks !

Re: Does Open-Source Cassandra 4 support mutual-TLS ?

[Dinesh Joshi]

> On Sep 22, 2021, at 2:02 AM, Bowen Song  wrote:
> Out of curiosity, I have two further questions.
> 
> 1. I know the client can optionally provider a certificate for the TLS 
> handshake, but is it possible to require the client to provide a certificate?
> 

Yep, you can turn on require_client_auth under the client_encyrption_options in 
Cassandra YAML to 
https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L1160 
 This 
requires the CQL client to provide client certificates.

> 2. Does Cassandra check that the username matches the client certificate? 
> E.g. TLS client certificate is issued to "bob", but logging in CQL using the 
> username "charol".
> 
no. The client certificates that you provide should be trusted by the server's 
truststore for the connection to succeed. Thats it. AFAIK there isn't an 
accepted secure standard to encode a "username" inside a TLS client certificate 
that we can use to derive a principal. 
> If the answer to Q2 is "no", it would mean that the TLS client certificate is 
> used for primary authentication (but not authorisation), and the CQL username 
> & password will be used for secondary authentication and authorisation. 
> Anyone who has a valid client certificate and private key pair can 
> impersonate any CQL user if they know the username and password. Depending on 
> the threat model, this may or may not pose a security risk.
> 
The client certificate can be used to ensure that it is a trusted client. If a 
bad actor is able to not only obtain a valid client certificate but also the 
private key pair then you have bigger issues :)

In 4.0 the IAuthenticator interface has changed slightly to pass down the 
client certificates that the server receives. In theory one can create an 
implementation of this interface that can derive an identity from the client 
certificates and then use that to perform authentication. This would give you 
what you're looking for. If you'd like, you can go as far as ignoring the 
username/password passed down from the cilent and only rely on the identity 
encoded in the certificate as your source of truth.

Dinesh
> 
> On 21/09/2021 23:16, Dinesh Joshi wrote:
>> It sort of supports it. You still need to send in the username/password 
>> credentials along with the client certificate to authenticate. Cassandra 
>> will not derive the identity purely from the client certificate.
>> 
>> Dinesh
>> 
>>> On Sep 21, 2021, at 11:59 AM, S G  
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> Does anyone know if opensource Cassandra support mutual-TLS ?
>>> The documentation doesn't conclusively deny or accept the support for the 
>>> same.
>>> 
>>> Thanks !

Re: Does Open-Source Cassandra 4 support mutual-TLS ?

[Bowen Song]

Out of curiosity, I have two further questions.

1. I know the client can *optionally* provider a certificate for the TLS 
handshake, but is it possible to *require* the client to provide a 
certificate?


2. Does Cassandra check that the username matches the client 
certificate? E.g. TLS client certificate is issued to "bob", but logging 
in CQL using the username "charol".


If the answer to Q1 is "no", it's not mutual-TLS.

If the answer to Q2 is "no", it would mean that the TLS client 
certificate is used for primary authentication (but not authorisation), 
and the CQL username & password will be used for secondary 
authentication and authorisation. Anyone who has a valid client 
certificate and private key pair can impersonate any CQL user if they 
know the username and password. Depending on the threat model, this may 
or may not pose a security risk.



On 21/09/2021 23:16, Dinesh Joshi wrote:

It sort of supports it. You still need to send in the username/password 
credentials along with the client certificate to authenticate. Cassandra will 
not derive the identity purely from the client certificate.

Dinesh


On Sep 21, 2021, at 11:59 AM, S G  wrote:

Hello,

Does anyone know if opensource Cassandra support mutual-TLS ?
The documentation doesn't conclusively deny or accept the support for the same.

Thanks !

Re: Does Open-Source Cassandra 4 support mutual-TLS ?

[S G]

Thanks Dinesh.
That is ok. Having mutual TLS ensures that the clients authenticate
themselves by certificates too.
The other authentication of static username/password adds the next layer of
authentication.
That ways a hacker now needs two keys (certificate and password) to connect
to the cluster.


On Tue, Sep 21, 2021 at 3:16 PM Dinesh Joshi  wrote:

> It sort of supports it. You still need to send in the username/password
> credentials along with the client certificate to authenticate. Cassandra
> will not derive the identity purely from the client certificate.
>
> Dinesh
>
> > On Sep 21, 2021, at 11:59 AM, S G  wrote:
> >
> > Hello,
> >
> > Does anyone know if opensource Cassandra support mutual-TLS ?
> > The documentation doesn't conclusively deny or accept the support for
> the same.
> >
> > Thanks !
>
>

Re: Does Open-Source Cassandra 4 support mutual-TLS ?

[Dinesh Joshi]

It sort of supports it. You still need to send in the username/password 
credentials along with the client certificate to authenticate. Cassandra will 
not derive the identity purely from the client certificate.

Dinesh

> On Sep 21, 2021, at 11:59 AM, S G  wrote:
> 
> Hello,
> 
> Does anyone know if opensource Cassandra support mutual-TLS ?
> The documentation doesn't conclusively deny or accept the support for the 
> same.
> 
> Thanks !