Implement ephemeral ssl certificates — if SSL is enabled but no certificates are provided by the user, let the server generate certificates in memory and use them.

It should not be necessary to make any application-level changes to handle the case where certificates are not provided by the user: TLS already supports this.

The TLS standard offers ciphersuites called DH_anon, which basically means "do a DIffie-Hellman KX to agree on a long-term symmetric key, but without verifying any server certificate. https://www.rfc-editor.org/rfc/rfc5246#appendix-C

This ciphersuite will protect against passive MITM, but not against active MITM as explained here, so it should be considered very weak against the typical threat model for Internet traffic in 2023, which includes pervasive active MITMs.

Additional reasons why this kind of thing should be done in the TLS layer (left to the TLS experts who write and test TLS libraries ) and not implemented at the application layer.

• Ephemeral certs could play havoc with any clients/library that use a trust-on-first-use approach to server cert validation
• Generating ephemeral certs will condition end users to expect frequent changes and mismatches in the server certificates, and to bypass them. (This is a common criticism of how SSH is typically deployed: users override and ignore cert mismatches constantly.)

Note that MDEV-31855 is a precondition for ephemeral certs. We won't implement ephemeral certs unless they can be protected against active MitM

Also:

• MariaDB connectors don't do trust on first use, they validate certificates on every use.
• End users won't expect frequent changes and mismatches in the server certificates and bypass them, because they won't know about the changes. The client will completely automatically and transparently validate certificates without involving the user.

Note that MDEV-31855 is a precondition for ephemeral certs.

This sentence makes me even more confused about MDEV-31855 than I was before.

We won't implement ephemeral certs unless they can be protected against active MitM

How is that possible?

An ephemeral certificate generated by the server on each connection is — by its very nature — one where the client cannot have any foreknowledge of that certificate’s contents or provenance.

So how can the client possibly distinguish the ephemeral certificate generated by the real/intended server from one generated by a MITM intermediary?

It seems like you should perhaps be writing up a design document that explains the overall approach here.

yes, sure. the design document is in MDEV-31855. There's a full high-level description of the new protocol extension.
I'd appreciate if you'd try to come up with attacks against it.

Also you can check the bb-11.3-serg branch with the implementation of MDEV-31855 and MDEV-31856.

see MDEV-31855 for the list of commits

OK to push

Testing done. Ok to push