[openssl-users] sendmail, openssl 1.1.1, tls1.3
Tomas Mraz
tmraz at redhat.com
Tue Oct 16 08:05:33 UTC 2018
On 10/16/2018 09:27 AM, Viktor Dukhovni wrote:
> On Tue, Oct 16, 2018 at 08:13:11AM +0200, Jakob Bohm via openssl-users wrote:
>
>>> 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.
>>
>> Just for clarity, how is an OpenSSL 1.1.1 client supposed to tell
>> the local validation code which CAs to trust, especially if loading
>> the list before entering a chroot jail?
>
> Loading CA files is not a problem in itself, the issue is that some
> (typically server) applications overload the CAfile as also being
> the source of CA hints to clients in certificate requests. This
> creates bloated server certificate request messages. With TLS 1.3,
> this is further compounded in applications that are *both* a server
> and client, and use the *same* context for both purposes. Once
> that happens, the CA hints are used in both directions.
What are the CA hints sent from client to server good for? This looks
like missing API in 1.1.1 as we clearly do not want to start sending
huge client helos just because of client sending the CA hints to servers
in TLS-1.3. This needs to be something that requires an explicit new API
call to set.
>
>> How is this different from the OpenSSL 1.0.x API?
>
> The API is identical, what's different is that TLS 1.3 makes the
> CA hints bidirectional, given such hints have never been useful
> before, it is IMHO just needless generality that's counter-productive.
> Perhaps OpenSSL should require an additional non-default configuration
> to enable transmission of the client's CA DNs to the server.
>
> Or perhaps separate the server->client and client->server CA name
> lists in the SSL context, so that setting one does not (surprise!)
> also set the other. Overloading the same setting for both directions
> may not have anticipated bidirectional use of contexts.
>
> Someone should perhaps open an issue to track whether anything needs
> to change here beyond advice to users, and if so what.
I've opened it:
https://github.com/openssl/openssl/issues/7411
Tomas Mraz
More information about the openssl-users
mailing list