Timeline for When is it appropriate to SSL Encrypt Database connections?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 2, 2012 at 17:24 | comment | added | Mike Samuel | @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. | |
| May 2, 2012 at 16:20 | vote | accept | Stellar Sword | ||
| May 3, 2012 at 19:01 | |||||
| May 2, 2012 at 15:51 | comment | added | Bruno | @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. | |
| May 2, 2012 at 15:48 | comment | added | Stellar Sword | @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. | |
| May 1, 2012 at 22:21 | comment | added | Mike Samuel | @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. | |
| May 1, 2012 at 21:55 | comment | added | Bruno | @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. | |
| May 1, 2012 at 21:50 | comment | added | Bruno | 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. | |
| May 1, 2012 at 21:31 | comment | added | Mike Samuel | @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. | |
| May 1, 2012 at 21:26 | comment | added | Bruno | 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? | |
| Apr 30, 2012 at 20:02 | comment | added | Mike Samuel | @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. | |
| Apr 30, 2012 at 16:45 | comment | added | Stellar Sword | 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. | |
| Apr 30, 2012 at 16:27 | history | answered | Mike Samuel | CC BY-SA 3.0 |