The server-side SNI support in OpenSSL seems to be targeted at HTTPS
virtual host configurations, in which each Virtual host is associated
with its own SSL_CTX object, initialized not only with a separate
key+cert+trust chain, but also with a separate cipherlist, list of
trusted CAs (really X509_STORE), plus various flags, options, ...
This works reasonably well for a suitably-small set of preloaded
virtual hosts. With Postfix, I'd like to not pre-load all virtual
(non-default name) keys, certs and trust chains, and of course not
pre-initialize multiple SSL_CTX objects.
Rather, I'd like to construct the necessary state on-the-fly, using
essentially a table (disk-resident indexed file) of (domain, PKCS#12 blob)
pairs.
There will be no support for separately tunable SSL options per target
hostname, the only variables from name to name are the contents of
the PKCS#12 containers associated with each name.
I'd like to (if it were possible) to share the X509_STORE, cipherlist and
all the other attributes of the primary (aka initial) SSL context with
the SSL contexts created (on the fly) for each non-default server name.
This would save the need to parse and load trusted CAs into memory
multiple times and to perform unnecessarily detailed initialization of the
"virtual" SSL_CTX objects to mirror already performed configuration of
the initial SSL_CTX.
One way to do this is to create "stub" SSL contexts that share all
state other than key+cert+extra_certs with the initial SSL_CTX.
/*
* create stub cert with no keys, certs or extra certs,
* but otherwise sharing all state with (for flags, ... cloning
* all state from) a full parent context.
*/
SSL_CTX *stub = SSL_CTX_new_stub(initial_ctx);
SSL_CTX_use_certificate(stub, cert);
SSL_CTX_use_PrivateKey(stub, pkey);
SSL_check_private_key(stub);
.. foreach chaining cert "x" ...
SSL_CTX_add_extra_chain_cert(stub, x);
This could be used with SSL_set_SSL_CTX() in the servername callback,
to associated the right certs and keys with the connection, without
otherwise perturbing the SSL state. When a stub context is freed, only
the key/cert/extra_certs would be freed, the rest would be owned by and
freed with the initial context.
This would significantly simplify the management of virtual hosts that
differ only in the cert.
A related question is how long the SSL_CTX created for a virtual host
needs to remain in memory. Can I destroy this context after the connection
is closed, or will that break session resumption? I want to keep a small
number of active virtual contexts in memory, and discard them when the
cache limit is reached, re-creating the context on the fly.
Does resumption of cached sessions require the original virtual session
to still be in memory? How are cipherlists handled when sessions are
resumed? Is the client limited to the ciphers of the initial context or
the ciphers of the virtual context?
There may be other ways of achieving the same goal (light-weight
creation/destruction of virtual host contexts), I am open to suggestions
and willing to contribute code 0.9.9 if that moves this forward.
Not sure whether this can be done while keeping the resulting interface
binary compatible with the existing (still tentative I gather, and in
any case not documented) SNI interfaces.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
