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 <bo...@bso.ng> 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<sg.online.em...@gmail.com> 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 !
