I am all for security in depth, but the www-data processes still has the private key in memory.
Makes it slightly harder to get at, through other vectors though.
One approach is to let one process do the ssl termination, and only that -- that raises the bar some. That process might be nginx -- running under a different uid -- or one of the many ssl-proxies.
I guess that's a big advantage of terminating SSL at the load balancers – dedicated hardware which is unlikely to end up with exploitable RoR/PHP or SQLi vulnerabilites – is probably somewhat less likely to lose your private TLS certs to an automated WordPress/Rails/cPanel/whatever zero-day scan...
For a site that's (apparently) hosting an article about a security vulnerability, they _really_ need to turn debug mode off.
For those wondering what I'm on about when the site starts functioning again, I got an error page akin to a Django page with `DEBUG = True`, listing useful information as the full path to the PHP script being run, the user it's being run as, , etc.
You are really protecting against local, non-root access to your box, especially when that user is the nginx child process. This can manifest itself in a number of ways, but most roads lead back to improper input sanitization and/or using user input in shell command execution.
Using the Unix file permissions to our advantage and the properties of fork'd child processes, you can scope your risk to a highly skilled adversary rather than the common adversary.
Note that not only is your SSL certificate at risk, but every file the web-server needs to read including configuration files containing passwords, API keys, and crypto keys.
10 comments
[ 2.9 ms ] story [ 28.3 ms ] threadFor those wondering what I'm on about when the site starts functioning again, I got an error page akin to a Django page with `DEBUG = True`, listing useful information as the full path to the PHP script being run, the user it's being run as, , etc.
Using the Unix file permissions to our advantage and the properties of fork'd child processes, you can scope your risk to a highly skilled adversary rather than the common adversary.
Note that not only is your SSL certificate at risk, but every file the web-server needs to read including configuration files containing passwords, API keys, and crypto keys.