Re: Using certificates and keys from a list
Doug Hardie <[email protected]> Thu, 9 Apr 2026 08:48:09 -0700
| Newsgroups | gmane.comp.encryption.openssl.user |
|---|---|
| Message-ID | <[email protected]> |
-- Doug > On Apr 9, 2026, at 03:24, Jochen Bern <[email protected]> wrote: >=20 > Am 09.04.26 um 00:24 schrieb Doug Hardie: >> once I set the keys to 0600, it no longer worked. The reason is >> that the startup code that runs as root is quite small. It >> doesn't know which keys will be required. In fact, those keys >> might not even exist yet. >=20 > I think that y'all are overdesigning this a bit ... Definitely. This app needs to access key files during the SSL Client Hello= processing. That is the first packet sent by the client after the TCP ini= tiation. It includes the SNI field which is needed to find the proper key.= All of this takes place prior to any client request. The only thing that= takes place before the client hello call back is the initialization of the= SSL parameters. The privilege is given back up at the end of the call bac= k. The one valid concern is that retaining the UID of root throughout the = remainder of the app might somehow reset the euid back to root. Hence, I a= m changing the last part of the call back to setuid to the unprivileged use= r. I believe that will prevent any follow on code from changing it. =20 Note, the app has been in daily use since the mid 90's. I am the only deve= loper of it, and I most likely have the only instance of it. There is no us= er written code involved. The protection is there so that any errors in th= e code will not affect any other processes. > if there's a need for the process to read secrets from files after startu= p (read: after potential malicious influence), then the content of those fi= les is, by definition, unprotected vis-a-vis the running, possibly subverte= d, application. Create a dedicated UID or GID for the process to run as and= let bog-standard permissions do their thing with access attempts from *els= e*where (short of local root). >=20 > Yes, this means that you might want to look into revocation mechanisms, s= horter lifetimes etc. as tools to get the damage threatened by leaked secre= ts reduced again. >=20 Root life time is just long enough to decode the SNI field and read the two= files into SSL. -- Doug --=20 You received this message because you are subscribed to the Google Groups "= openssl-users" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to openssl-users+unsubscribe-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org To view this discussion visit https://groups.google.com/a/openssl.org/d/msg= id/openssl-users/F3F631C7-3608-4366-A405-01274C01E3CA%40sermon-archive.info= .