[Question posted by a user on YugabyteDB Community Slack]
Question related to client to server encryption on https://docs.yugabyte.com/latest/secure/tls-encryption/client-to-server/
Is this mTLS? Is the rpc server verifying the rpc client? And does it cover ysql or ycql clients ?
When using something like yb-admin over tls, does the server verify a certificate presented by the yb-admin like tool?
Regarding client <-> server connections, for YSQL it’s mTLS. Mutual TLS (mTLS) is a type of authentication in which the two parties in a connection authenticate each other using the TLS protocol. See https://docs.yugabyte.com/latest/secure/tls-encryption/client-to-server/ for more.
For server <-> server, it’s mTLS for both YCQL & YSQL (the server uses an internal layer for server to server communication). See https://docs.yugabyte.com/latest/secure/tls-encryption/server-to-server/ for more information.
Related
I am using pyhthon3 requests library and want to request some resources from the server using HTTPS. So I use two way SSL authentication, and I have configured the server in a way which do not REQUEST for client certificate in response of 'client Hello' request.
As You can see IP xxx.xx.xxx.100 is the client and IP xxx.xx.xxx.207 is the server. So when the client sends 'Client Hello' to the sever, in response the server does not REQUEST for the client certificate, even though its two way SSL authentication.
So as per my requirements, how can I stop the process of handshaking and data sharing immediately in such case? Or how to force the server to REQUEST for client certificate?
... even though its two way SSL authentication.
It's not. Just because the client has the certificate to do mutual authentication, does not mean that this certificate is actually used. It is only mutual authentication if the server actually requests it using a CertificateRequest (which is clearly not done) and the client then providing the requested certificate.
... how can I stop the process of handshaking and data sharing immediately in such case?
You can't. There is no API for this.
And I'm not sure what kind of sense such a requirement would make. The client has successfully authenticated the server which should be all needed by the client to exchange data with the server. The server instead might want to know who the client is before sending specific data. So authenticating the client before providing such data makes sense from a server perspective, but not from a client one. This would be like you refusing to drive a car if nobody is checking your drivers license.
Or how to force the server to REQUEST for client certificate?
This fully depends on the kind of server. Different servers need different configuration. For example with nginx see ssl_verify_client.
In the case where its beeing used a websocket protocol between a client (webpage) and a server.
Is it possible for third parties to spoof the connection in the handshake or even after the connection has been established?
Websockets do not directly provide authentication. If you build it over TLS (i.e. WSS), then you will use the TLS session to authenticate the parties using server and client certificates, exactly like HTTPS vs HTTP.
If you build your websocket over HTTP, then yes, it is completely possible for a third party to spoof the connection (and also to eavesdrop). If your HTTPS/WSS system does not properly validate certificates, then that also can be spoofed.
I am trying to set the client to nodes SSL encryption for one of our client.
I have confusion regarding the functionality of setting require_client_auth in client_encryption_options in cassandra.yaml and what configuration needs to set from client and cassandra node in case I set require_client_auth to true.
Password authentication is already set,now investigating if there might be any additional advantage to having both ("authenticator: PasswordAuthenticator" and "require_client_auth: true") turned on
As Jim stated, require_client_auth doesn't have anything to do with Cassandra's auth system. It is an additional level of security configuration for client-to-node SSL.
When you implement client-to-node SSL and enable require_client_auth you are enabling what is known as Two Way SSL. Instead of the Cassandra client simply verifying the identity of the server, the server also verifies the certificate used by the client. This doc One Way and Two Way SSL and TLS (Peeples K. 2015) has a good description of this process:
Two-way SSL authentication is also referred to as client or mutual authentication because the application acting as an SSL client presents its certificate to the SSL server after the SSL server authenticates itself to the SSL client.
Establishing the encrypted channel using certificate-based 2-Way SSL involves:
A client requests access to a protected resource.
The server presents its certificate to the client.
The client verifies the server’s certificate.
If successful, the client sends its certificate to the server.
The server verifies the client’s credentials.
If successful, the server grants access to the protected resource requested by the client.
On the other hand, with One Way SSL the client only verifies the server's certificate (from the same doc).
The advantage of Two Way SSL would be in knowing that the Cassandra nodes will not allow a connection from an unknown client certificate.
IMO, one Way SSL still offers a decent degree of security. The dev team will need to present a cert which validates up through the same CA (certificate authority) as the cert from the Cassandra nodes. Two Way SSL might be useful in a large org, helping to keep out connections from applications that have not first talked with your team.
I believe the require_client_auth is for SSL (certificate) communication between the client and server, and that the client must identify itself (you can have it so that the server is the only one that identifies itself).
I have a scenario where I have 2 applications.
The service, providing some data
The UI client, displaying the data from the service
I want the communication between the service and the client to be secure (encrypted).
What should I use for that? Is the SSL common protocol for such usage, or do we typically use something else?
Assuming your service is exposing a standard REST API (or similar) that your front-end is calling: yes, SSL is the standard. It provides:
Confidentiality: the data is encrypted between the client and the server and cannot be read by an attacker. Typically uses the RSA algorithm.
Integrity: an attacker cannot tamper with the messages sent between the client and the server. Typically implemented using HMAC
Authentication: the client is able to check that the server it is talking to is actually yours, and not an attacker. Basically, the server shows to the client a certificate signed by the Certificate Authority having issued the SSL certificate (e.g. VeriSign), that proves its identity.
All that is assuming SSL is configured properly on the server's side: up-to-date ciphers, no support for outdated ones, proper key length (2048 bits or higher), etc.
Note that a client can be anything calling your service: a browser-based application, a mobile application, a smart watch application...
You can use SSL Labs to check if your SSL configuration looks secure.
I'm developing a client-server app, the client is an iPhone device that communicants with my c# server. The client and server use a textual protocol that i have designed to exchange messages over TCP sockets. Can someone please give me some guidelines how to add basic security to this app?
At this moment the only security element i have is client authentication with log in username and password. But for example anybody can see and read the messages sent between client and server without any problem...
In the mobile environment the user of the application has more control over the device than you do as a developer. There is no way to hide a secret password or key. You must account for a malicious client, so be careful about the functionality that you expose.
Sending the username and password in plain text is a violation of OWASP a9. You should consider using SSL/TLS or HTTPS.
Have you looked at openssl? SSL are cryptographic protocols that provide secure communication. SSL will prevent others from listen on the stream between your client and server.
One thing more you should do is to validate all server input, to prevent executing malicious code on your server. For example if you have a database where you store user input you should take a look at SQL injection.