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.

Dexter
  • 405
  • 1
  • 3
  • 10

4 Answers4

25

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

Bruno
  • 10,765
  • 1
  • 39
  • 59
  • 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. – Dexter May 03 '12 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 May 03 '12 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. – Dexter May 03 '12 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.

Mike Samuel
  • 3,873
  • 17
  • 25
  • You've convinced me but I'm playing devil's adv. Can you tell me what kind of DB information you think would need such an added layer of security. Every security layer needs a cost-benefit analysis, if a hacker wants to get into my DB and would spend time penetrating the local network, the only motivation would be if the database has valuable CC or banking information right? There is also the cost of learning a new concept like encrypting with SSL database connections. – Dexter Apr 30 '12 at 16:45
  • 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 Apr 30 '12 at 20:02
  • How does SSL between the web server and the DB server helps protect against whatever bad intentions an admin who's able to log on to the web server can have anyway? – Bruno May 01 '12 at 21:26
  • 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 May 01 '12 at 21:31
  • The logging argument works indeed, but I was more thinking about the admin on the web server itself (I'm assuming the best case scenario where the internal network is fully secure, i.e. fully dedicated for this purpose; in doubt there, SSL is a definite yes). An admin there could potentially perform a local downgrade attack on the SSL channel for example (and relay the traffic to the DB via SSL so it wouldn't notice on that end). I just think the angles of attack where SSL adds something extra are actually quite narrow. – Bruno May 01 '12 at 21:50
  • 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 May 01 '12 at 21:55
  • @Bruno, I think I agree. If an admin can sit on either endpoint, then securing the channel won't stop them because exfiltration is relatively easy. I have worked in shops where devs like me wrote apps but could not deploy them and compliance required something of a wall between devs and admins so each had limited control over aspects of the code running, and different accounts/privileges were used for routine admin tasks and ones that were in response to particular problems that require more latitude to fix. – Mike Samuel May 01 '12 at 22:21
  • 1
    @Bruno I'm concerned about delays, whenever I work with SSL, huge delays occur because of encrypting and decrypting data transmitted. In addition, I'd have to figure out how ASP.net can SSL-protect connection strings and how entity framework will be using SSL. What kind of millisecond delays will it add to my queries? I'm not worried about administrators, that is silly, if administrators want to spy on their own data, they can go ahead and do so but they can already view all the data in the database. – Dexter May 02 '12 at 15:48
  • 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 May 02 '12 at 15:51
  • 2
    @Dexter, these [benchmarks](http://www.datadirect.com/resources/jdbc/connection-pooling/benchmarks.html) 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 May 02 '12 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.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • 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? – Dexter Apr 30 '12 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 Apr 30 '12 at 16:13
  • 3
    @Dexter, often web-frameworks provide [connection pooling](http://en.wikipedia.org/wiki/Connection_pool) 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 Apr 30 '12 at 16:17
  • Obviously though, most security in systems are a probability. If you already implemented some IP checking whitelisting, do you really need to create overhead with SSL security between Web server and DB server if they are locally connected and firewalled? Assuming your administrators are trustworthy and no other vulnerable application services are running (plus if your local network is penetrated you have bigger issues at hand). – Dexter Apr 30 '12 at 19:41
  • 3
    @Dexter, I believe you do not *need* SSL. But when it comes to extra layers, [Jeremy Banks describes it very clearly](http://stackoverflow.com/a/6765186/463304) 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 Apr 30 '12 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 Apr 30 '12 at 19:51
  • @polynomial don't be absurd. I am obviously looking for compelling arguments to convince me as a skeptical user so that I have strong arguments when someone asks "why is the site so slow?" It's quite presumptious of you to assume just because I'm arguing I've "made up my mind." I really think it is counterproductive when stackoverflow users tell you to go away when you don't say "I must accept your every advice without questioning anything and immediately give you best answer" to your every statement. It's hostile and unproductive. – Dexter May 02 '12 at 15:51
  • @George Bailey I don't know the cost yet. But obviously determining the cost itself is a cost. The cost of learning how to setup SSL between webserver and database server, getting that to work with Entity Framework and ASP.net, and the cost of slowed down website due to constant encryption-decryption that is absolutely necessary on every transmitted message. If the cost was so small, then every website in the planet would be SSL. I am wondering how badly it might slow down the connection. – Dexter May 02 '12 at 15:58
  • @Polynomial furthermore, please don't ever dismiss arguments again in comments. If all engineers and scientists behaved this way, nothing in science would advance because whenever something is questioned it would be dismissed for "you've already made up your mind because you're arguing with me." Debate is exactly how progress is achieved. Science, especially computer science and IT security works on consensus not on "listen to my advice or go away." I wish more debate occurred on stackoverflow, it might create higher quality answers. – Dexter May 02 '12 at 16:07
  • @Dexter and polynomial - comments are not the place for this. The chat room is. Comments should be used to request clarification of an answer or concept, so the actual answer (or question) can be refined. Ideally then comments can be deleted as the value in SE is the Q&A part. – Rory Alsop May 02 '12 at 16:45
  • @RoryAlsop Indeed, but also people need to see and remember that you shouldn't just dismiss people for asking clarifications on questions which is what I did. – Dexter May 02 '12 at 18:45
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.

symcbean
  • 18,278
  • 39
  • 73