When is it appropriate to SSL Encrypt Database connections?
It looks like the two previous answers to this question more or less strongly recommend to turn on SSL anyway, but I'd like to suggest a different reasoning angle (although I'm not recommending not to turn on SSL).
The two key points in assessing whether you need SSL or not are (a) what SSL protects you against and (b) what the thread model is: enumerate the potential threats.
SSL/TLS protects the transport of information between a client (in this case, your web server) and a server (in this case, your database server) from tampering and eavesdropping by anyone on the network in between (including able to get on those two machines).
To assess whether SSL is useful, you need to assume that the attacker is in a position to perform the attack SSL is designed to protect you against. That is, the attacker would need to be in a position to sniff packets on the network or on either machines.
If someone in a position to sniff packets from the database server, they're likely to have root/admin access to that server. Using SSL/TLS at that stage will make no difference.
If someone is in a position to sniff packets on the network between the web server and the database server (excluding those machines), using SSL/TLS will prevent them from seeing/altering the application content. If you think there might be a chance this is possible, do turn on SSL. A way to mitigate this would be to use two network cards on the web server: one to the outside world and one to the inside LAN where the DB server is (with no other machines, or in a way that you could treat them all as a single bigger machine). This network forming the overall web-farm or cluster (however you want to call it) would be physically separated and only have one entry point from the outside: the web server itself (same principle for a reverse proxy head node).
If someone is in a position to sniff packets on the head node (the web server) itself, they're likely to have root access there (processes run by non-root users on the machine, shouldn't be able to read packets that are not for them). In this case, you would have a big problem anyway.
What I doubt here is whether enabling SSL actually protects you much in this scenario.
Someone with root access on the web server will be able to read your application configuration, including DB passwords, and should be able to connect to the DB server legitimately, even using SSL.
In counterpart, if you did assume that this warrants the use of SSL (because it might be harder to look into what the processes actually do rather than just looking at the network, even if you have root control on the machine), this would mean you would also want to turn for localhost communications (e.g. if you have other services on your web server, or in the situation where both DB server and web server were on the same machine).
It's not necessarily a bad thing to be over-cautious, but you have to put your question in the context of what attackers could also do should they be in a position to perform an attack against what the security measure (SSL) protects you against, and whether this security measure would prevent them from achieving their goal anyway, once in this position.
I think the window is actually quite narrow there (assuming your back-end network really is secured, physically, not just by some firewall amongst a number of machines).
When the local network that includes the database server and clients might include other processes then you should encrypt the connection between the two.
This is almost always the case since, even if you assume that the local network is impenetrable (you shouldn't), besides the database client and server there are usually
- administrators that need to be able to log in and fix problems or do updates
- log collectors that need to grab files without sensitive data and move them somewhere else
- replicators that need to copy database content for off-site backup or to feed large low-sensitivity tables to data-mining systems
- monitors that need to check to see whether the others are still alive
Of those, only the replicators need to have access to tables with sensitive data, but any of these processes can be compromised by bad actors within your IT dept.
Encrypting all channels that carry sensitive data keeps honest people honest, gives you a defense in depth, and helps you narrow the search when problems do arise.
Keep in mind that anyone who is on the same network as your server might be able to sniff the traffic or perform a man-in-the-middle attack. SSL should prevent this, assuming it's set up properly. You should also set up a firewall on the database server and only allow connections from trusted IP addresses.
My suggestion is to turn it on, then turn it off only if you think it's causing performance (or other) problems. That way you've cut your attack vectors down significantly.
In reality, the overhead of SSL encryption over the network is going to be minimal, especially when compared to the load of processing SQL queries. You'd gain more performance by optimising your queries and server performance configuration than by disabling SSL.