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. -- Cheers, Jeremy
