<div>A SSL_CTX api seem like a good idea to provide additional guarantees to applications.</div><div><br></div>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?<div><br></div><div>This ought to be a transparent scenario for a legacy application which *at the same time* also do frequent cert rolling.</div><div><br></div><div>Would it be appropriate to record some excerpts of this discussion in github gist? I can be the secretary, if that would be uncontroversial.</div><div><br>El lunes, 31 de agosto de 2020, Viktor Dukhovni <<a href="mailto:openssl-users@dukhovni.org">openssl-users@dukhovni.org</a>> escribió:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Aug 31, 2020 at 11:00:31PM -0500, David Arnold wrote:<br>
<br>
> 1. Construe symlinks to current certs in a folder (old or new / file by file)<br>
> 2. Symlink that folder<br>
> 3. Rename the current symlink to that new symlink atomically.<br>
<br>
This is fine, but does not provide atomicity of access across files in<br>
that directory.  It just lets you prepare the new directory with<br>
non-atomic operations on the list of published files or file content.<br>
<br>
But if clients need to see consistent content across files, this does<br>
not solve the problem, a client might read one file before the symlink<br>
is updated and another file after.  To get actual atomicity, the client<br>
would need to be sure to open a directory file descriptor, and then<br>
openat(2) to read each file relative to the directory in question.<br>
<br>
Most application code is not written that way, but conceivably OpenSSL<br>
could have an interface for loading a key and certchain from two (or<br>
perhaps even more for the cert chain) files relative to a given<br>
directory.  I know how to do this on modern Unix systems, no idea<br>
whether something similar is possible on Windows.<br>
<br>
The above is *complicated*.  Requiring a single file for both key and<br>
cert is far simpler.  Either PEM with key + cert or perhaps (under<br>
duress) even PKCS#12.<br>
<br>
<br>
> Does it look like we are actually getting somewhere here?<br>
<br>
So far, not much, just some rough notes on the obvious obstacles.<br>
There's a lot more to do to design a usable framework for always fresh<br>
keys.  Keeping it portable between Windows and Unix (assuming MacOS will<br>
be sufficiently Unix-like) and gracefully handling processes that drop<br>
privs will be challenging.<br>
<br>
Not all applications will want the same approach, so there'd need to be<br>
various knobs to set to choose one of the supported modes.  Perhaps<br>
the sanest approach (but one that does nothing for legacy applications)<br>
is to provide an API that returns the *latest* SSL_CTX via some new<br>
handle that under the covers constructs a new SSL_CTX as needed.<br>
<br>
    SSL_CTX *SSL_Factory_get1_CTX(SSL_CTX_<wbr>FACTORY *);<br>
<br>
This would yield a reference-counted SSL_CTX that each caller must<br>
ultimately release via SSL_CTX_free() to avoid a leak. <br>
<br>
    ... factory construction API calls ...<br>
    ctx = SSL_Factory_get1_CTX(factory);    -- ctx ref count >= 1<br>
    SSL *ssl = SSL_CTX_new(ctx);            -- ctx ref count >= 2<br>
    ...<br>
    SSL_free(ssl);                          -- ctx ref count >= 1<br>
    SSL_CTX_free(ctx);                      -- ctx may be freed here<br>
<br>
To address the needs of legacy clients is harder, because they<br>
expect an SSL_CTX "in hand" to be valid indefinitely, but now<br>
we want to be able age out and free old contexts, so we want<br>
some mechanism by which it becomes safe to free old contexts<br>
that we're sure no thread is still using.  This is difficult<br>
to do right, because some thread may be blocked for a long<br>
time, before becoming active again and using an already known<br>
SSL_CTX pointer.<br>
<br>
It is not exactly clear how multi-threaded unmodified legacy software<br>
can be ensured crash free without memory leaks while behind the scenes<br>
we're constantly mutating the SSL_CTX.  Once a pointer to an SSL_CTX<br>
has been read, it might be squirreled away in all kinds of places, and<br>
here's just no way to know that it won't be used indefinitely.<br>
<br>
-- <br>
    Viktor.<br>
</blockquote></div>