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.

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.

Hmm, good point. I guess it's a shame we can't pass TLS connection state between processes as easily as socket handles?

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

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.