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=
.