Determine which SSL handle should be used in callbacks on accepted connections

[t8m]

Copying the relevant comments from the discussion in this PR: openssl/openssl#25874

@mattcaswell: Question: It doesn't affect this PR but I wonder what happens in the feature/quic-server branch with callbacks. Have we always been guaranteed to have called SSL_accept_connection before the first TLS callback might be called? If not there might not be a user SSL to pass to the callback yet!!

@t8m: Hmm... this might be unfortunately the case for all the callbacks that can be triggered by the initial handshake frames from the client - perhaps we should delay processing these until SSL_accept_connection() is called?

@vdukhovni: Well, the whole point about "The user SSL" is that it is some object to which the user might have attached some "extdata", i.e. something created well before the handshake. In the case of server callbacks, that'd be the acceptor SSL handle that was listening for incoming connections, not the accepted SSL that materialises after.

Which handle will be used in callbacks here?

If perhaps some callbacks really need the accepted connection, while others (typically at least those related to session management) need the preëxisting acceptor connection, we have a problem, and potentially need to either copy extdata when creating the accepted SSL handle, or to give the user an early opportunity to decide how the accepted SSL should be "decorated" (new callback that gets to see both handles), before any other callbacks are invoked.

[mattcaswell]

Possibly we should proactively create the "user" SSL object when we create the channel, even if SSL_accept_connection has not yet been called. There could also be a new callback on channel creation passing the user SSL to give the application an opportunity to decorate it as they see fit. SSL_accept_connection would just pass back the pre-created user SSL.

[vavroch2010]

After the draft design is created, it must be reviewed by @mattcaswell and/or @vdukhovni

[nhorman]

I'm having a bit of trouble seeing how the creation of the user SSL object is going to be a problem here. to level set, I'm assuming that the user ssl object is the one represented by the tls member of the quic_conn_st struct.

On the client side this is created via SSL_new->ossl_quic_new->ossl_ssl_connection_new_int which is, rather by definition done prior to the sending or receipt of any handshake messages.

On the server side, we we don't create the qc->tls object until such time as we receive an Initial packet from a client, so I could see how that could be concerning, but, until such time as the server receives an Initial packet from a client containing a client hello, all packets on the listening port pass through port_default_packet_handler, and all frames are dropped or responded to at the port level (i.e. retry and version negotiation frames). Only after a packet has been validated do we pass it up to the tls record layer for handling, and that doesn't happen until port_default_packet_handler calls port_bind_channel->port_make_channel->ossl_quic_channel_new->ch_init, which creates the new channel, the associated QUIC_CONNECTION, and associates it with the new channels user SSL object (ch->tls which was created in ossl_quic_channel_new).

That channel gets placed on the ports incomming_channel_list and doesn't exist as far as the TLS record layer is concerned until such time as SSL_accept_connection->ossl_quic_accept_connection is called. Only after that will records be read by the TLS layer from the accepted channel, at which point the user SSL object exists and can be passed to any callbacks required.

It might be a problem if someone attempted to create a listener SSL object and then called SSL_connect on it or some such, but that would be a programming error, as you should never attempt to connect using a listening socket.

Is there something I'm missing here?

[t8m]

I'm having a bit of trouble seeing how the creation of the user SSL object is going to be a problem here. to level set, I'm assuming that the user ssl object is the one represented by the tls member of the quic_conn_st struct.

Unfortunately this is a wrong assumption. This internal tls object is NOT the user SSL object. The user SSL object is the object that the user has a direct access to - until the server addition it was simply the quic connection SSL object. The user does not have any access to the internal tls object.

With Matt's suggestion to add a new callback that would give you the SSL object newly created during SSL_accept_connection() I think it would be the best choice to use the newly created SSL object as the user SSL for these callbacks.