Hi all, so I'm wondering how to securely deal with TLS certificates on a server
that's grown to host multiple services (website, XMPP, soon email as well).
Specifically how to handle permissions and to what degree certificates should be
separated.
(I recognize this is a long email. I'm unsure how to break down my thoughts
further)
I know that I could add a load of Subject Alternative Names to one big
certificate, but I have a couple of concerns with this.
1) If I understand it right, if there's a security issue with one program and an
attacker gains arbitrary read, and the effective user id can read the private
key, the exposure is greater than it has to be (that is to say, domains that are
completely unrelated to the insecure program are exposed). Daemons outside of
base unfortunately often lack privilege separation to the extent that it exists
in base, so there may not be a separate user to handle private keys, and then
the whole thing has the potential to blow up later.
2) A long list of Subject Alternative Names means that anyone connecting to the
web server can see all of the additional subdomains that are unrelated to the
web server being hosted. This is really a nitpick compared to the first point,
as even without this being the case there are other methods of enumeration and
discovery (nmap and friends), and relying on DNS entries being hidden seems like
a bad idea.
The best way I can think of how to handle this so far, and "best" is used very
loosely since I don't think it's a perfect solution, is to split the keys up,
add a separate group, and modify `/etc/ssl/private`.
```
# groupadd tls
# usermod -G tls _prosody
# chown root:tls /etc/ssl/private
# chmod 750 /etc/ssl/private
```
Then the private keys within would all have 0400 permissions, user and group
being the same (so _prosody:_prosody for XMPP-related TLS). I noted that the
default is 700 permissions on `/etc/ssl/private` with root:wheel ownership. Is
the approach I've just outlined with adding a group and modifying permissions a
bad idea?
Even if it makes sense to do it this way, I still have a separate issue in that
when two or more services need the certificate for the root domain, they'll end
up sharing it, and I'm unclear what the right way to fix that problem is. If
it's only services in the base system, that's one thing. But Prosody also has
this issue with the way I set it up. Currently it's configured so that usernames
can be in the form "u...@example.com" rather than "u...@xmpp.example.com"
(similar to how email usernames use the root domain). This means it needs the
certificate for the root domain so that authentication can take place over TLS,
and that breaks the separation.
For some services, it can make sense to use relayd(8) and let that handle TLS
instead, which simplifies things since relayd has proper privilege separation
and can even use SNI. But I'm unsure how this could be done with something like
Prosody since XMPP uses STARTTLS (outside of exceptions to that rule like
XEP-0368).
What can I do to manage this better? Any ideas/suggestions are very welcome.
Thank you for reading all of this if you made it here.
