24

Let's say I have a web server I setup, and then a database server.

However, they are communicating locally and are behind firewall. In my opinion, no SSL is needed here right?

The only time to use SSL to encrypt the database connection would be between a web server that exists in a server that remotely communicates with a database server that is located somewhere else right?

I've seen guidelines for security before that advocate securing with SSL the database connection but it was vague on when to use it.

Improve this question

4 Answers 4

Reset to default
26

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).

Improve this answer
3
  • 1
    That is exactly a good detailed explanation I was looking for. Basically unless the web server and database server are physically in different locations and are connecting over a remote IP, then they may be vulnerable. However, if they are communicating on some local network the only way to sniff those packets would be someone who is also within that local network (and we have whitelisting anyway). SSL will provide no added security if they already have access to the local network. Even if they hack a local process, then they have your certificate anyway.
    – Stellar Sword
    Commented May 3, 2012 at 19:08
  • 1
    @Dexter, on the contrary, it will provide extra security if they already have access to the LAN (that's exactly when it's useful). It won't provide much added security if they already have access to those two machines between which you're making the connection. If there are other devices on that LAN, it's potentially useful (just being being a NAT or a firewall is often not enough).
    – Bruno
    Commented May 3, 2012 at 19:10
  • Sorry I said that wrong. SSL will add security if they have access to the LAN but not the local machines. SSL will add security if the two servers communicate over the internet. However, if they have local machine access, then it doesn't add security. Plus, you have bigger problems if they've already accessed the LAN. If you're communicating within LAN though, usually SSL is not necessary, because they would need to already have hacked a machine within the LAN (which shouldn't happen with the hosting firm). Though if I was a bank, added security like this would definitely help.
    – Stellar Sword
    Commented May 3, 2012 at 19:24
11

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

  1. administrators that need to be able to log in and fix problems or do updates
  2. log collectors that need to grab files without sensitive data and move them somewhere else
  3. replicators that need to copy database content for off-site backup or to feed large low-sensitivity tables to data-mining systems
  4. 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.

Improve this answer
10
  • 2
    @Dexter, many kinds of information have economic value. CC and banking info, Passwords (salted or weakly salted) that can be used to compromise other accounts, Sales leads, Strategic forecasting data. Often companies want to keep their lists of valued employees out of the hands of recruiters, so even fairly innocuous data like employee evaluations can be considered sensitive. Finally, if the organization that owns the data is a target lawsuit, then data protection is a legal issue -- minimizing leaks and forcing companies to go through discovery keeps the playing field level.
    – Mike Samuel
    Commented Apr 30, 2012 at 20:02
  • 1
    @Bruno, Rather than just needing the ability to run code on any machine in the local network, they have to have specific authority. Logging onto a machine with DB privileges may generate more of a log trail and to steal data they would probably have to muck with a particular image on that machine which means someone investigating abuse has to look at a smaller window of logs to find the culprit.
    – Mike Samuel
    Commented May 1, 2012 at 21:31
  • 1
    @Dexter, generally speaking, you should assume that the connection to the DB needs to be confidential, don't make your decision based on what data might be in the database (assume it has to be protected anyway). Even if your website only displays public data obtained from the DB server, you'd still want to protect the DB password to prevent modifications of the public data for example. If there is a possibility that the connection might be eavesdropped, do use SSL.
    – Bruno
    Commented May 1, 2012 at 21:55
  • 2
    @Dexter, it's the kind of thing that depends so much on the environment and on the configuration that you'll only find out by trying. As it's already been suggested, make sure you're using pooled connections to avoid to do the handshake repeatedly.
    – Bruno
    Commented May 2, 2012 at 15:51
  • 2
    @Dexter, these benchmarks give you an idea of how expensive JDBC/ODBC connections are compared to pooling. The cost of an SSL handshake is definitely something to consider when you have many clients connecting to a few servers, but when you've got few:few, it'll likely be dominated by the DB connection handshake so you'd probably get better performance by pooling or using some other strategy that amortizes both handshakes over multiple operations.
    – Mike Samuel
    Commented May 2, 2012 at 17:24
4

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.

Improve this answer
11
  • SSL handshakes can take 30-40 seconds, SQL queries take milliseconds. I don't think you can say SSL will be minimal in overhead. If it is a local network, how can there be others connected to it without having physical wired access to the router?
    – Stellar Sword
    Commented Apr 30, 2012 at 16:10
  • 6
    They don't take anywhere near 30 seconds (if they do, something is very wrong) but I will grant you that they are an overhead to keep an eye on. You can mitigate this by pooling connections and sharing them across query sources. An alternative is to implement ipsec on your network.
    – Polynomial
    Commented Apr 30, 2012 at 16:13
  • 3
    @Dexter, often web-frameworks provide connection pooling since establishing and tearing down a database connection is an expensive operation compared to a single small query. Connection pooling will amortize SSL handshakes just as well as it amortizes database connection setup and teardown.
    – Mike Samuel
    Commented Apr 30, 2012 at 16:17
  • 3
    @Dexter, I believe you do not need SSL. But when it comes to extra layers, Jeremy Banks describes it very clearly in my opinion (though he is talking about another question, the answer still applies). So.. Now the question becomes what does it cost you? If the cost of setup/performance is very small, then go ahead anyway, because the benefit may be less small.
    – 700 Software
    Commented Apr 30, 2012 at 19:48
  • 2
    @Dexter It sounds like you've already made up your mind that SSL is a "bad thing" for your setup. If you're not here to listen to our advice, what are you trying to achieve?
    – Polynomial
    Commented Apr 30, 2012 at 19:51
0

Let's say I have a web server I setup, and then a database server...communicating locally and are behind firewall

Leaving aside the fact that this architecture sucks in terms of availability...

  • do you trust everyone and everything "behind the firewall"?
  • do you believe that your firewall is perfect?
  • can you predict that you will never need to connect remotely to support higher availability, migrate your datacentre or perform a backup?
  • is the default authentication mechanism for the dbms so secure that it cannot be subverted?
  • do you have a deployment process which ensures the database credentials cannot be compromised?

If your answer to any of these is not a definite yes then you might benefit from the additional assurances of using a suitably configured SSL connection. The performance cost is negligible even without relying on persistent connections (although this too can be all but eliminated by routing the traffic through a persistent tunnel). It comes down to simply working out if the cost of configuring the SSL (a couple of hours work) is more than the liability.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .