On Fri, Mar 27, 2020 at 08:20:55PM +0000, Jeremy Harris wrote:
> > Right, you're running out of space by trying to send too many
> > CA names. It is better to have this fail, so you can figure
> > what is trying to dump your entire trusted CA list (of names)
> > to the server, than to actually have that silently "work".
>
> It's /etc/pki/tls/certs/ca-bundle.crt (on Centos 8) and
> it's being loaded using SSL_CTX_set_client_CA_list()
> into the client, supposedly to be the acceptable CAs
> for the cert sent by the server.
That function should only affect the server -> client direction.
Briefly, in OpenSSL 1.1.1 it affected both the client and server
directions, but this was fixed in OpenSSL 1.1.1a.
If the distro started with 1.1.1 and only backported security fixes, you
could be running an OpenSSL version with the unintentional bidirectional
setting.
Another possibility is that your system-wide openssl.cnf file has a
"RequestCAFile" or "ClientCAFile" setting. Both unfortunately set not
only the server->client direction, but also the client->server
direction. This may be a bug (oversight), the second of these
should not touch the bidirectional list.
"ssl/ssl_conf.c" line 500:
static int cmd_RequestCAFile(SSL_CONF_CTX *cctx, const char *value)
{
if (cctx->canames == NULL)
cctx->canames = sk_X509_NAME_new_null();
if (cctx->canames == NULL)
return 0;
return SSL_add_file_cert_subjects_to_stack(cctx->canames, value);
}
static int cmd_ClientCAFile(SSL_CONF_CTX *cctx, const char *value)
{
return cmd_RequestCAFile(cctx, value);
}
"ssl/ssl_conf.c" line 883:
int SSL_CONF_CTX_finish(SSL_CONF_CTX *cctx)
{
...
if (cctx->canames) {
if (cctx->ssl)
SSL_set0_CA_list(cctx->ssl, cctx->canames);
else if (cctx->ctx)
SSL_CTX_set0_CA_list(cctx->ctx, cctx->canames);
else
sk_X509_NAME_pop_free(cctx->canames, X509_NAME_free);
cctx->canames = NULL;
}
return 1;
}
Can you confirm whether any such directive is present in your
system-wide openssl.cnf (possibly via .include)?
> > Perhaps your "openssl.cnf" (Linux distro mistake?) causes the
> > damage for all applications even without explicit code to that end
> > in Exim? Or you're calling something to make it happen.
>
> The Exim config is saying to use that file, so I do have a workaround
> point there.
It is actually not easy to avoid using the system-wide config.
It is loaded by default during library initialization, and
you need custom initialization calls to avoid loading it.
> However, the question is: what is [1] the proper fix? We want to
> accept "the usual, pretty big, set of well-known CAs". Is that an
> incorrect way of telling OpenSSL that list?
It makes some sense to send a CA list to clients, but ideally one that
is not too large. In Postfix I recommend a small or no CAfile (from
which the CAlist is initialized), and the bulk of the trust store
configured via a CApath (which is not used to send CA names to clients).
Most clients (real MTAs, not random Java apps) handle an empty CA list
just fine, and use the (at most) one client cert they have.
> And how come it only fails under resumption and when a client-cert is
> also used?
Here, I am not sure, but perhaps this is because the extension is only
valid with TLS 1.3, and on resumption we already know the server
protocol version. On initial handshakes the protocol might be
TLS 1.2, and perhaps as a result the list is not sent???
> 1] We also need to code to be compatible across a wide range
> of OpenSSL versions. Minimising #ifdeffery is a factor.
Understood, I'm in the same boat with Postfix.
--
Viktor.
