resumption problem

Jeremy Harris jgh at
Fri Mar 27 20:20:55 UTC 2020

On 26/03/2020 00:58, Viktor Dukhovni wrote:
> On Thu, Mar 26, 2020 at 12:40:08AM +0000, Jeremy Harris wrote:
>> Looks like I'm wrong, from the behaviour.
>> It's the second of the possible places, and "i" is 129.
>> It appears to be failing the   WPACKET_sub_allocate_bytes_u16()
>> call.  %rsi before the call, which I think should be
>> the "namelen" arg, has value 172.
> 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.

The load call doesn't have a return value to check. The
list presented had 133 entries.

>  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.  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?  And how come it only fails under resumption and
when a client-cert is also used?

1]  We also need to code to be compatible across a wide range
of OpenSSL versions.  Minimising #ifdeffery is a factor.

More information about the openssl-users mailing list