A SSL_CTX api seem like a good idea to provide additional guarantees to applications.
Maybe Openssl - used as a library - can return to the other legacy applications that the certificate is "deemed not valid any more" whenever they try to use an outdated pointer? This ought to be a transparent scenario for a legacy application which *at the same time* also do frequent cert rolling. Would it be appropriate to record some excerpts of this discussion in github gist? I can be the secretary, if that would be uncontroversial. El lunes, 31 de agosto de 2020, Viktor Dukhovni <openssl-us...@dukhovni.org> escribió: > 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. > > 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. > > -- > Viktor. >
