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.
Related
Usually when a user logs in, the user details are sent to the sever to authenticate the user. How are these credentials protected in the best way during flight?
Main Questions :
I understand the passwords are many times hashed, keeping them secure. Also TLS maintains the in-flight security, But is that the only way the transaction details are kept secure or do websites add any of their own layer of security?
In our case, we want to send a passcode to the backend, where another API will be called (that uses password grant) of a third party application. We cannot hash the password, we'll need it in the backend. Will TLS be sufficient for securing it in flight?
We were also planing to implement and secure the passcode by RSA (public key) on the client side and unlock it on the backend for use. Should we consider RSA?
I understand the passwords are many times hashed, keeping them secure. Also TLS maintains the in-flight security, But is that the only way the transaction details are kept secure or do websites add any of their own layer of security?
There are very few cases where layering more cryptography on top of TLS are beneficial. Your case doesn't seem to fit them. So TLS should be enough. TLS already provides encryption in transit. RSA would do the same. Defense in depth means layering different security mechanisms on top of each other.
You might hash the password on the client side creating an intermediate password, but considering your 2. question, this is not what you can do.
In our case, we want to send a passcode to the backend, where another API will be called (that uses password grant) of a third party application. We cannot hash the password, we'll need it in the backend. Will TLS be sufficient for securing it in flight?
Yes, but let the client (your server) validate the certificate chain and don't accept protocol downgrades.
We were also planing to implement and secure the passcode by RSA (public key) on the client side and unlock it on the backend for use. Should we consider RSA?
No, just use TLS 1.2 or higher with a valid server certificate and let the client validate the certificate chain (browser does that automatically for you).
Keep in mind that TLS needs a trust root. Most client side libraries as well as many browser use the trusted root store of the operating system. A certificate chain presented by the server should end in one certificate that is in the trusted root store.
You could use a self-signed certificate, but then the client would need to pin the public key of that self-signed certificate.
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).
When creating any kind of application web,api etc; This days the best practices recommend to secure endpoints by using TLS, but what we can learn from the cloudbleed issue, is that it may not be enough.
Therefore I would like to know what could be done to keep a certain level of security even when TLS is compromised.
For web applications what I currently use is jsencrypt, basically encrypts all data on client browser side before it is sent, but in order to to this I need first to exchange a shared secret (token/cookie) between the server and client, but when dealing with API's that don't support javascript what could be used?
Regarding the exchange of tokens, by instinct it may be obvious to say use OAUTH, OpenID Connect, json tokens , but all of them require or delegate trust to TLS, and again when this is compromised it became useless.
If I am right OpenID could be used without SSL to share a "common secret" by doing Diffie–Hellman key exchange, is there something similar that could be implemented keeping in mind that if TLS gets compromised, easy measure could be taking like revoking tokens or changing "salts" ?
For now I think by following the gpg or rsa (private/public) keys is the way to go, in a way that probably everyone could have access to the public keys but will not be available to see the content of some data signed to a specific user.
But question remains in how to exchange that very first "known secret" between client and server avoiding a possible man in the middle attack considering TLS can't be trusted.
The problem of exchanging the first "known secret" is the same for all protocols, SSL or not. SSL is a public key infrastructure where the basic information that needs to be distributed is the public key of the root certificate of the certificate issuer. The public keys for all ssl certificate issuers are distributed with the browser installation.
Any protocol will depend on some information that is communicated between the server and client in a different channel from the channel where the communication is established. If you don't trust the SSL infrastructure, you will have to send this information by email, postal mail, sms, or by some other means.
However, your problem does not start with the keys neccesary for the encryption libraries you are using in you web application. Your very web application (the javascript files) are also sent from the server to the web browser over SSL. If your SSL communication is compromised by a man-in-the-middle, this man-in-the-middle is also probably able to change the web pages and javascript code that you send to the browser. He could just rewrite your application and remove all encryption code, add new fields and messages for the user, send the user to a different site and so on.
The SSL infrastructure is really a cornerstone in web security, and a neccessity for web applications. Without it, you would have to build a custom protocol for sending encrypted web pages and write a custom browser that would understand this protocol.
With all that said, it is of course possible to add a tiny layer of extra security on top of SSL. You may i.e. create a private/public keypair for each user, send a public key to the user and encrypt all messages from your server to the user with the private key. This could protect against a scenario where a main-in-the-middle is able to listen to the communication but not able to change your messages.
I currently develop a small system consisting of an embedded server (including a small display) and some mobile devices (at the moment just Android phones).
These mobile devices should be able to talk to the embedded server over a secure channel. For this purpose, the server generates a self-signed SSL certificate during the very first boot process.
If a new mobile device should be connected to the server, the server displays a QR code consisting of:
Server IP
SSL certificate fingerprint
Random device ID
The user scans this QR code using his mobile device. The mobile device connects to the server and checks whether the SSL certificate fingerprint matches the one scanned before.
Is this considered secure? If not, how would you solve this problem?
An alternative approach:
On the very-first boot, the server generates a certificate request and sends it to a central CA server which signs the certificate. The client devices has installed the CA certficate and verifies the server certificate against it.
However, everyone could send a certificate request to the CA server and would get a signed certificate. (One could propably implement some authentication for the CA server using a "master key" but once that is extracted from a system image, the whole authentication becomes useless). In addition this setup requires a central server which I like to avoid since the product may be used in a "offline" environment.
Yes, this is considered secure because the fingerprint of the server's certificate is transferred to the client via a trusted mechanism (being physically next to the server to receive the fingerprint via a difficult to tamper with transport mechanism). If a MITM attack were to be attempted after the initial setup, even though server name would be the same, different keys would have been generated so the fingerprint would be different and the client would detect this and can appropriately reject the communication.
It could also be argued that this method is more secure because the client does not need to trust a 3rd party to verify the authenticity of the certificate. CAs do occasionally issue fraudulent certificates.
I'm building an application that needs to establish a secure connection between a client and a server, providing web services.
I need to guarantee authenticity for both (client and server), the server will also be handling the client authorization to access the data and files.
If thought to do it using an EKE-like algorithm to authenticate both, but these relies on a previously shared secret.
I could use the client password as the shared secret, but I would need to securely establish that password upon the client sign up, in this case I would need a secure channel, and authenticate the server (the client needs to know which server he is registering into).
I would rather avoid using a CA to provide certificates with the server public keys, because its a lot of extra code for just one small job, and it wouldn't be the best solution, because I would just have to trust the CA.
Ultimately this is to let the client send (client-)encrypted files to the server and share them.
Any alternatives that I'm missing out?
Tl;Dr How to stablish a secure client/server channel, authenticating the server, without CA, know public keys, or previous
SSL/TLS offers wide choice of authentication mechanisms, including pre-shared secrets, OpenPGP keys etc. So you can go for SSL and avoid reinventing the wheel.
Also you can sign and encrypt individual data messages (again using OpenPGP as a variant).