8

If I follow the reasoning of a colleague it seems you should never run Apache Webserver or Tomcat on a Windows server if you want to keep the https certificate safe.

Let me explain before this question evolves into a Windows vs Linux troll battle.

For example when using Apache Tomcat for a https website the private key is stored in a keystore. For Tomcat to be able to use this key we have three options:

  1. Not use password on keystore;
  2. Keystore password needs to be entered when starting Tomcat service;
  3. Keystore password is set in plain text in a config file.

Using option 3 seems the most practiced. But anyone with access to this file and the keystore is able to extract the private key. Obviously you can filesystem protect the keystore and config file. It seems though that linux offers more options to separate access to those files for different processes. This reasoning led to the conclusion I started with.

I am not familiar with how Windows or IIS handle this, but expect this works somehow similar under the hood. My problem is I don't know for sure. How is IIS able to use the certificate in Windows if no one enters it's password? Or is just stored in the registry instead of a config file? And is setting high certificate security equal to option 2?

Could anyone explain to me how this works?

Btw. I am not interested in HSM. For now I am keen on knowing if and how Windows/IIS protects a certificate or private key not using option 3.

I have searched, but could not find conclusive answers. I have browsed 30 pages tagged with "certificates" and used google. I find it hard to distill a definitive answer from them. Below I mention the sources I found of some help. I really hope you can help me or point me to the right source.

Security on stackExchange:

  • How secure is my private key in the Windows Digital Certificate store?
  • How should I store SSL keys on the server?
  • How to store a private RSA key for an application?
  • What are some good design practices for cross-platform certificate storage?

Microsoft:

  • [TechNet blog] What is a strong key protection in Windows?
  • [TechNet, EFS] How Private Keys Are Stored

Various sites:

  • [ServerFault] How to manage a web servers SSL private key protection (password vs. no password)?
  • [CodingHorror] Keeping Private Keys Private
  • [SecurityInnovation] How to Test for Insecure Key Store Vulnerabilities
  • [RootSecurity] How to export “non-exportable” certificates from the Microsoft Certificate Store
  • [Symantec] How Attackers Steal Private Keys from Digital Certificates
AviD
  • 72,138
  • 22
  • 136
  • 218
Gos Bilgon
  • 136
  • 1
  • 5
  • It is worth noting that the baseline configuration for Linux systems typically supports only POSIX file permissions. These are fairly limited, compared to Windows, where files have rich access control lists. Modern Linux filesystems *do* support ACLs, but they are not enabled by default. If you take the time to enable them, then filesystem security on Linux and Windows is at par. Out of the box, though, Windows actually supports better, more fine-grained file permissions than Linux does -- in other words, Windows offers more options to separate access to those files for different processes. – Jonathan Gilbert Oct 27 '16 at 19:14

1 Answers1

14

A generic remark is the following: if you can reboot the machine, and the server becomes operational again automatically, without any further human intervention, then, by definition, the machine disk contents contain everything that the machine needs to access the private key. Correspondingly, someone gaining full access to the machine (as "root" on Linux, "Administrator" on Windows) will be able to recover the private key as well.

On Windows, software-based private keys are stored in the DPAPI. To make the story short, the private key is linked to an account (the machine's own account for the "Local Machine" store) and the protection ultimately relies on encryption using the account's password as key. For an IIS which starts automatically, the corresponding password must be written somewhere in the entrails of the system. There can be layers of encryption and indirection, but it can be unravelled by anybody with sufficient rights. See this answer for pointers as to how to do that practically.

Also, if someone gains administrative privileges on the live machine, then he can just attach to the running Web server process and plunder its RAM contents directly, with ReadProcessMemory().

So any protection will be, ultimately, relative to how well the operating system will prevent unauthorized users from gaining administrator privileges. From that point of view, there is not much difference between Apache/Tomcat and IIS: you could store the private key for Apache in a file and set some ACL to make this file readable only from the specific user who will run Apache. People with administrative rights will be able to bypass that, but, as explained above, they can do anything on the machine.


Now there can be quantitative subtleties. Down to the core of the machine, there is the kernel; kernel code, by definition, is God. It can read and write all the RAM, access all the hardware. The kernel is also the gatekeeper who decides who can do what. In the view of the kernel, each applicative code runs with a set of privileges, which describe exactly what the code can do. Some privileges are god-equivalent, meaning that a process which has that privilege can arrange, more or less directly, for obtaining the same power as the kernel. In a traditional Linux system, any root process is god-equivalent, since root can create and load kernel modules, i.e. custom code right into the kernel itself. By transitivity, any process who can take control of a process with god-equivalent privileges is also god-equivalent.

God-equivalent processes are juicy targets for attackers. There more such process there are, the more probable it becomes that one of them has an exploitable vulnerability that will allow the attacker to achieve godhood. Thus, reducing the size and scope of god-equivalent process may help in increasing practical security. There will still be, deep in the machine, some god-equivalent code (if only the kernel itself), but fine tuning may help keeping that code small.

Linux and Windows, by default, are roughly equivalent in that respect (a lot of process which run as root / System account), but offer different tools to trim that down. On Linux you would play with chroot and, more generically, SELinux. On Windows you can do a lot of tuning and restricting with Group Policies. In both cases it is quite easy to lock yourself out, so take care.


Summary: There is nothing wrong with Apache/Tomcat on Windows. Protections applied on private keys as used by IIS are not qualitatively different, or stronger, than access rights on files. A good sysadmin will achieve a similar security level in both cases, on the same machine.

In any case you would be well advised not to let any unprivileged user run arbitrary code on servers with sensitive data. Experience shows that when attackers are allowed to run unprivileged code locally, the number of exploitable holes raises sharply.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • Tnx for your thorough explanation how things work in general. I am still hoping on a more specific answer in the lines of: On windows certificates and keys for system use are located in folder such and such. Standard no password is used. One has the option to set a password (see screenshot X in blog `http://here/or/there`) but that would require manual entering booting the machine. Or providing the system with the password which it would store in the registry at `HKLM\such\and\such`. The registry and folder are protected by ACL. Anyone with enough privileges has access. – Gos Bilgon Dec 20 '13 at 15:27