2

I'm developing a set of internal websites and services for a customer who has high levels of bureaucracy and strict formal rules about many things, one of them being "not storing passwords in plain text".

So, when they inspected my system configuration manual, they immediately pointed out that they could not accept storing private key passwords in a text file for Nginx to load on startup. It doesn't matter that the file is readable only by root.

My arguments, such as "if someone got root access to your server then you have bigger problems than leaked private keys", "The attacker could extract the keys from server process RAM anyway, no matter what encryption is being used", "It's a recursive problem because if I encrypt the password file, Nginx will need the password to decrypt the password file to decrypt the keys" did not work.

It seems, the customer is just used to how IIS works - the private keys are protected by CNG mechanisms and you don't have to store plain text passwords or keys or API tokens anywhere.

How do I achieve that on Ubuntu and Nginx without making things too messy?

I really don't want to migrate everything to Windows and then explain the customer why they need one more Windows Server licence when the initial idea was to use free Ubuntu server.

Improve this question
10
  • 2
    There are many options to store secrets, and a lot of it depends on your environment and automation vs security tradeoffs. You can find some discussion here. I would note that your arguments are indeed a bit weak.
    – Marc
    Commented May 19, 2020 at 10:01
  • I feel like the requirement is intended for application user accounts, not system things.
    – multithr3at3d
    Commented May 19, 2020 at 11:49
  • 1
    Yeah, this does happen sometimes. There's options including encrypting the files and adding the key to the kernel's keyring, though you'd certainly have to enter a passphrase once at every boot. Will it satisfy their requirements if the local file system is encrypted?
    – Pedro
    Commented May 19, 2020 at 15:39
  • @Pedro Yes, entering password on server reboot (but not on every Nginx daemon restart) might be acceptable. If only I knew how to configure Nginx itself to work with keyring and TLS certificate key passwords... Internet searches somehow don't yield anything immediately usable.
    – JustAMartin
    Commented May 19, 2020 at 16:09
  • It would have to be implemented by hand, I'm 99% sure nginx knows nothing about the keyring. method would be: system boots, requests password, adds to keyring, nginx would be wrapped in a script that pulls the password, decrypts certs (or cert pwd file) into RAM, starts nginx then scrubs the file.
    – Pedro
    Commented May 19, 2020 at 16:24

2 Answers 2

Reset to default
1

It is important to understand exactly what the requirements are and how they can be met, as in what is an acceptable solution to both parties. As everybody always says, security is about compromises.

  • You can have the pvt keys encrypted and nginx will ask for the password every time it starts. This is OK security wise, but not practical at all;

  • You can have the pvt keys encrypted and have nginx read the passwords off a file. Personally I find this to not have a security benefit if the password file is to be stored on the file system since there is still enough information to decrypt and reveal the pvt keys, particularly to the root user. It's merely an additional step;

  • You can have a system whereby you enter a passphrase into the kernel keyring every at every boot and use that to control encryption of the nginx password file. Again the passphrase can be extracted off the keyring by root, so this is an additional step that's trickier to compromise than just reading a file. Plus you need to handle the temporary decryption of the password file: A possible solution is to decrypt the password file into RAM, start nginx then scrub it from RAM immediately after the daemon starts;

    • You could make use of a hardware device instead of the kernel keyring that either contains keys or contains material required to decrypt content, again to expose the password file temporarily. This will make it more difficult to compromise the keys, it is not dependent on a hardware device being available;
Improve this answer
2
  • 1
    Thank you for the options, I'll try to discuss them with the customer. I'm still somewhat disappointed with the fact that GNU/Linux community hasn't yet invented some "de facto standard" solution for the issue, at least as good as Microsoft's CNG, especially considering how popular Linux-based operating systems are for web servers.
    – JustAMartin
    Commented May 19, 2020 at 19:56
  • Understandable. Linux admins usually live with unencrypted private keys readable by root only, since that requires full compromise of the host or the file system to recover. That said I agree it is a gap that I'd rather see covered somehow. As it turns out (from the answer below) there is support for HSM backed TLS key storage on nginx: nginx.com/blog/…
    – Pedro
    Commented May 20, 2020 at 7:45
0

Being a Linux guy, I don't know much about Microsoft IIS. But, reading https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/network/cng-certificates-overview, it seems like 'CNG' that you mention in your question and following comments is just an SSL/TLS key management solution using a hardware security module (HSM). You can use a hardware security module for SSL/TLS with NGINX as well - see https://www.nginx.com/blog/protecting-ssl-private-keys-nginx-hashicorp-vault/#hsm.

Improve this answer
2
  • CNG doesn't actually need hardware, it piggybacks the "secure storage" onto Windows user authentication mechanisms. Essentially, it's like some kind of an keyring "on steroids" that is automatically used by Microsoft IIS web server to store private keys without the need to store passwords in plain text anywhere. Not as secure as a hardware module, but with well-defined API and integrated into many Windows-specific products.
    – JustAMartin
    Commented May 20, 2020 at 8:00
  • 1
    CNG, like PKCS#11, like JCE, like Bouncycastle, are each -- to varying degrees "cryptographic service APIs/providers". They do the same things, just each slightly differently, and each with maybe a different focus. All of those, by the way, can leverage an HSM when available. To be clear, CNG is not "just an SSL/TLS key management solution". Yes, it can do that. No, that is not what is... and it works with or without an HSM, just with different levels of security.
    – rip...
    Commented May 21, 2020 at 3:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .