How does the symmetric key get exchanged in SSL/TLS handshake?

Question

I've been reading a lot about SSL/TLS handshake between a client and a server and many articles on it are very contradictory.

Some say that the symmetric key that will be used to communicate between the two parties is transmitted from the client to the server (ofc, encrypted with the server's public key) and that's it.

Some say that a DH algo is being used and first the client sends a pre-master secret to help generate the shared key (why is the pre-master secret encrypted in the first place, an attacker won't gain any confidential info).

What's confusing is the overall flow of the generation on the shared symmetric key. a) Is DH being used at all (and if not, how is the symmetric key being generated, the client suggests it, sends it via RSA encryption and that's all?)

And b) If DH is being used, who starts first? There must be someone who first suggests the overall prime numbers to use for generating the secret, and then sends their computation (or is the overall algo determined up-front)?

Answer 1

As you already noted, there are two ways to exchange symmetric session keys: through key encipherment or through key agreement (which is based on Diffie-Hellman algorithm). Both algorithms are not used at the same time. For example, Microsoft SChannel client reads bits from server certificate's KeyUsages extension (which is a bit string) and depending on what bit is set, the key exchange algorithm is used.

When key encipherment is used:

1. client and server exchange supported cipher suites and agree on a common cipher (which is supported by both parties).
2. client uses selected algorithm and parameters to generate symmetric key and encrypts it with server's public key (asymmetric encryption, RSA or ECC, for example).
3. server uses its private key to decrypt the key and this key is used to protect session. No DH is involved here.

In the case of Diffie-Hellman (key agreement), there is no much difference on who starts, because parties share common prime number p and generator number g and both parties MUST agree on these values. These numbers can be agreed on in public. So, the agreement initiator is just a protocol's message syntax matter.

After that the following process occurs (which is well-defined):

1. Clients sends its DH public key to server.
2. Server computes the secret session key by using the information contained in its private key and client's public key.
3. Server sends its DH public key to client.
4. Client computes the secret session key by using the information contained in its private key and server's public key.
5. Both parties now have the same session key, which can be used for encrypting and decrypting data. The steps necessary for this are shown in the following procedure.

Detailed DH key exchange algorithm is described in RFC2631.