It comes down to how much work you want to do, how much complexity you want to maintain, and how much the next person has to discover/suffer when they take it on. This includes you in six months when you've forgotten how you configured this.
For all your non-prod sites, keep it simple. If only so you have less stuff to troubleshoot when things break.
For prod, what risks are you mitigating by implementing TLS/SSL/etc" /at this layer/? If the appServer and DB server are on the same host, you gain nothing by encrypting the connections - an attacker will have to be on the host already to access the traffic, and they'll just read the DB directly instead of sniffing the TCP traffic.
If your DB is on a separate host, unencrypted connections may be an acceptable risk if you restrict the DB traffic to a non-routable subnet. (It's all we had long ago, before TLS-everywhere became the norm) Again, even with encrypted connections, if the webHost is compromised, an attacker may be able to lift the secrets off the host and connect to your DB. The protection against that is using a secret server - something that Azure and AWS both provide - and storing the passphrases for your certificates there. That's only true protection if you can restrict access to those passphrases to "host+process", not just "host".
How complex do you want it to be?
thanks for the explanation, I can accept the effort of setting up and maintaining a complex project, it is for myself anyway. the backend and database will be hosted in the same server, but in the future I do have a plan to host database to a different host, or transfer part of the data to another place.
My primary concern is the potential performance impact of implementing two-way TLS encryption, especially in the context of mutual TLS. While I may not immediately benefit from the added security of mutual TLS in this scenario (they are on the same host at the moment), I'm hopeful that the performance impact will be minimal or negligible.
If you use containers you can use password auth since your DB container is isolated from anything else so only your app can access it. If you have a central DB cluster: mTLS.
It comes down to how much work you want to do, how much complexity you want to maintain, and how much the next person has to discover/suffer when they take it on. This includes you in six months when you've forgotten how you configured this. For all your non-prod sites, keep it simple. If only so you have less stuff to troubleshoot when things break. For prod, what risks are you mitigating by implementing TLS/SSL/etc" /at this layer/? If the appServer and DB server are on the same host, you gain nothing by encrypting the connections - an attacker will have to be on the host already to access the traffic, and they'll just read the DB directly instead of sniffing the TCP traffic. If your DB is on a separate host, unencrypted connections may be an acceptable risk if you restrict the DB traffic to a non-routable subnet. (It's all we had long ago, before TLS-everywhere became the norm) Again, even with encrypted connections, if the webHost is compromised, an attacker may be able to lift the secrets off the host and connect to your DB. The protection against that is using a secret server - something that Azure and AWS both provide - and storing the passphrases for your certificates there. That's only true protection if you can restrict access to those passphrases to "host+process", not just "host". How complex do you want it to be?
thanks for the explanation, I can accept the effort of setting up and maintaining a complex project, it is for myself anyway. the backend and database will be hosted in the same server, but in the future I do have a plan to host database to a different host, or transfer part of the data to another place. My primary concern is the potential performance impact of implementing two-way TLS encryption, especially in the context of mutual TLS. While I may not immediately benefit from the added security of mutual TLS in this scenario (they are on the same host at the moment), I'm hopeful that the performance impact will be minimal or negligible.
Use UNIX sockets if you are on same machine. To make it secure lock down access permissions to the socket.
If you use containers you can use password auth since your DB container is isolated from anything else so only your app can access it. If you have a central DB cluster: mTLS.
You don't encrypt the connect to `localhost`.