Hi Ashlen, The best way to handle your concerns is to review httpd, OpenSMTPd, and other projects code and send a patch to these project to handle Certificates in a more secure way. This way you can help yourself and the others.
Bests, Ali Farzanrad Ashlen <euryd...@riseup.net> wrote: > 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. > >
