> On Oct 15, 2018, at 9:22 PM, Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> wrote:
>
>> pointing the CACertFile to 750KB file with 149 certificates.
>
> With 149 certs, and typical CA names O(80) bytes, we're looking at
> ~12KB of cert names, which should fit into an extension that can be
> up to 64KB in size. So overflowing the extension size limit would
> not be my first guess. If you make the CA bundle available (send
> it to me off-list?) I can take a closer look.
[ Carl sent me the CA bundle off-list ] With the provided CA bundle
I was able to easily reproduce the same symptoms with:
$ openssl s_client -requestCAfile bundle.pem -connect localhost:12345
Running this under a debugger the failure happens at certificate #143
because the client hello packet overflows its maximum allocation:
$6 = {
buf = 0x0000000100724200
staticbuf = 0x0000000000000000 <no value available>
curr = 16364
written = 16364
maxsize = 16384
subs = 0x0000000100727700
}
So even though the extension is allowed to be up to 2^16 bytes, it
seems the client HELLO is expected to fit into a single TLS record
of at most 16K bytes.
Given enough crud in the CA bundle, and a client misconfigured to
to spill its guts to the server, by sending the names of all the
trusted CAs, the limit is not too hard to exceed.
The work-around is to send *zero* CA names to the server, Sendmail
SHOULD NOT configure the SSL_CTX for the client connection to with
preferred CA names. If that is not configurable, then keep the
CA file as short as possible, empty if possible, else just one
root CA, and everything else in CApath (yes "hashed" with the
various symlinks in place to each cert, one per file).
As for the 16K limit, and whether we should be sending client
CA names without further indication from the (TLS 1.3) client
to do so, I'm hoping Matt Caswell and or other team members
will chime in.
--
Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
