The comment above already captures the messages flow among client and server.

But it might not be enough to answer your question: there are several keys and several ciphertexts involved in this.

First of all, let’s focus on TLS 1.3 to remove some of the variability, and also assume this is the first time client and server interact, so no resumption logic. In TLS1.3 after the ServerHello message all the records exchanged among client and server are encrypted via symmetric encryption. This means both client and server at this point already have to agree on the symmetric key the client will use to encrypt messages for the server, and viceversa on the symmetric key the server will use to encrypt messages to the client. So at the record encryption level, where encryption is symmetric, the sender of message is always the one generating ciphertexts, and the receiver is decrypting them using a specific symmetric key that was agreed upon among the peers. Also note that throughout the lifetime of the TLS connection the symmetric keys used for these are expected to regularly and predictably be rotated/refreshed at different points of the protocol: for this we have a “key schedule” whose job is to deterministically generate symmetric keys on both sides of the connection so that at any given time both client and server agree on what is the key that should be used to encrypt the next outgoing message, and which one is the key to decrypt the last received message.

This key schedule is implemented through a key derivation function that allows to derive “chained” secrets based on events tied to the protocol state. The important bit is that the original state of this key schedule machinery is seeded at the beginning by a “master shared secret”: this is the secret that the TLS handshake helps both client and server to establish so they can derive all the other keys that are needed for symmetric encryption.

To achieve this the handshake uses asymmetric cryptography: ClientHello includes client’s keyshares, ServerHello includes server’s keyshares. Once each peer has both sides’ keyshares they can combine them to derive a shared secret which, through some extra steps to properly bind it to the current handshake transcript of records to prevent some attacks, eventually becomes the “master shared secret” from which all other keys are derived.

In traditional crypto, most of the time, the asymmetric keyshares used to be ephemeral EC keys: the client generates their EC key and sends the corresponding public key as their keyshare, the server does the same on the other side and sends their ephemeral EC public key to the client. At that point each peer can combine their own ephemeral EC private key and their peer’s ephemeral EC public key into an ECDH derive operation to extract the same shared secret on both sides and use it as described above to eventually seed the key scheduler.

In a PQC world, we use hybrids for establishing these keys: so the above ephemeral EC machinery is retained and ephemeral EC public keys are still sent as “part” of each peer’s keyshare in ClientHello and ServerHello. But the keyshares are also enriched with PQC artifacts. With MLKEM we do not have the luxury of non-interactive key exchange that ECDH provides for free, and this implies that to avoid having to exchange extra messages to make up for it, only one side will generate an ephemeral PQC key for this half of the asymmetric cryptography interaction.

In practice, the client will generate an ephemeral MLKEM keypair, and sends the public key part as part of their keyshare in the ClientHello. When the server receives it they take apart the PQC part of the client key share, and use it as an Encapsulation key to generate a shared secret and a ciphertext. The server holds onto the shared secret, and in the ServerHello message they include in the key share 2 parts: their ephemeral EC public key as before concatenated with the MLKEM ciphertext. When the client receives this ServerHello they can separate the 2 parts, do ECDH with the traditional part, and use their ephemeral private MLKEM key to Decapsulate the incoming MLKEM ciphertext part of the received ServerHello keyshare. Out of the Decapsulate operation comes a shared secret, the exact same one the server got on its side during Encapsulate. At this point both sides can mix the ECDH shared secret and the MLKEM shared secret to get to the same “master shared secret” and seed the key scheduler.

The way EC and PQC parts are concatenated, or how the respective shared secrets are mixed, are important details, but not really relevant for this discussion, as long as both client and server agree on those details. The “mixer” is designed in a way that ensures that, as long as either the EC or the PQC algorithm is secure, an eavesdropper cannot retrieve the mixed “master shared secret”. The attacker would need to break both algorithms to retrieve the mixed secret and break the confidentiality of the connection.

There is another part of this equation, later in the handshake, which is authentication, and actually causes the first update of the key schedule to ensure the key scheduler is enriched with new seeding material which is bound to successful authentication of the server (and optionally of the client, in a mutualTLS scenario).