On 2020-09-01 06:57, Viktor Dukhovni wrote:
On Mon, Aug 31, 2020 at 11:00:31PM -0500, David Arnold wrote:
1. Construe symlinks to current certs in a folder (old or new / file by file)
2. Symlink that folder
3. Rename the current symlink to that new symlink atomically.
This is fine, but does not provide atomicity of access across files in
that directory. It just lets you prepare the new directory with
non-atomic operations on the list of published files or file content.
But if clients need to see consistent content across files, this does
not solve the problem, a client might read one file before the symlink
is updated and another file after. To get actual atomicity, the client
would need to be sure to open a directory file descriptor, and then
openat(2) to read each file relative to the directory in question.
Most application code is not written that way, but conceivably OpenSSL
could have an interface for loading a key and certchain from two (or
perhaps even more for the cert chain) files relative to a given
directory. I know how to do this on modern Unix systems, no idea
whether something similar is possible on Windows.
On NT-based window, the undocumented Zw family of file I/O syscalls
would do what you call "openat()", "current dir" is in fact a directory
handle plus string equivalent stored in a user mode variable in one
of the core shared objects, which is why rmdir fails if it is the current
directory of any process.
The above is *complicated*. Requiring a single file for both key and
cert is far simpler. Either PEM with key + cert or perhaps (under
duress) even PKCS#12.
Does it look like we are actually getting somewhere here?
So far, not much, just some rough notes on the obvious obstacles.
There's a lot more to do to design a usable framework for always fresh
keys. Keeping it portable between Windows and Unix (assuming MacOS will
be sufficiently Unix-like) and gracefully handling processes that drop
privs will be challenging.
Not all applications will want the same approach, so there'd need to be
various knobs to set to choose one of the supported modes. Perhaps
the sanest approach (but one that does nothing for legacy applications)
is to provide an API that returns the *latest* SSL_CTX via some new
handle that under the covers constructs a new SSL_CTX as needed.
SSL_CTX *SSL_Factory_get1_CTX(SSL_CTX_FACTORY *);
This would yield a reference-counted SSL_CTX that each caller must
ultimately release via SSL_CTX_free() to avoid a leak.
... factory construction API calls ...
ctx = SSL_Factory_get1_CTX(factory); -- ctx ref count >= 1
SSL *ssl = SSL_CTX_new(ctx); -- ctx ref count >= 2
...
SSL_free(ssl); -- ctx ref count >= 1
SSL_CTX_free(ctx); -- ctx may be freed here
To address the needs of legacy clients is harder, because they
expect an SSL_CTX "in hand" to be valid indefinitely, but now
we want to be able age out and free old contexts, so we want
some mechanism by which it becomes safe to free old contexts
that we're sure no thread is still using. This is difficult
to do right, because some thread may be blocked for a long
time, before becoming active again and using an already known
SSL_CTX pointer.
It is not exactly clear how multi-threaded unmodified legacy software
can be ensured crash free without memory leaks while behind the scenes
we're constantly mutating the SSL_CTX. Once a pointer to an SSL_CTX
has been read, it might be squirreled away in all kinds of places, and
here's just no way to know that it won't be used indefinitely.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
