On 2017-03-30 at 17:11 -0400, Viktor Dukhovni wrote:
> > On Mar 30, 2017, at 4:40 PM, Heiko Schlittermann wrote:
> > You're right, Exim picks up the cert/keys per connection, as the
> > relevant options are expandable at runtime. (But, as far as I know,
> > currently not based on the key that is requested (so we do not support
> > multiple key setups for the same CN, as far as I know. But I may be
> > wrong, as always.)
Key appears to be expanded; this is `tls_expand_session_files()` in
tls-openssl.c and tls-gnu.c and re-expands the key for each.
Introduced with commit 7be682ca5 and I thought you were right that
historically we didn't re-expand the key, but apparently I did have it
expand the key from the beginning. GnuTLS support was a few commits
later when I rewrote the GnuTLS support.
> What this means is that session resumption can't possibly work in
> Exim (which is OK, Exim is not obligated to optimize the handshake
> overhead of high-volume TLS traffic). Consequently, it would be
> best if Exim did not generate SSL session ids or vend TLS session
> tickets.
Sounds right; we should consider adding this to the default value of
openssl_options, which theoretically exposes _every_ `SSL_OP_` to
administrator control.
As to the ECC/RSA support: I've looked at the code required and it's all
requiring newer OpenSSL, so I punted until after we dropped support for
older OpenSSL. 4.89 is out, after the "official" drop but with old
OpenSSL still working and is probably the last release to support those
old OpenSSL builds.
IIRC, the other thing which was blocked waiting was switching to using
some DSA loading routines for DH parameters, to be able to load q values
too, for dodging small subgroup attacks as a pre-requisite before Exim
can ever consider reusing an SSL configuration.
Filed:
https://bugs.exim.org/show_bug.cgi?id=2092
Subject: Should support dual-key configuration with lists of keys/certs
-Phil
