

Nginx and SSL root key security - kamaln7
https://blog.kamalnasser.net/post/nginx-and-ssl-root-key-security

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

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

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

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

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

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

