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)?

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.

  • 1
    ECDH is not (key) encryption, it is key agreement just like DH, in fact it is DH over a different type of group. Although DH and ECDH as algorithms allow either party to go first, in SSL/TLS protocol the server sends first, both the field specification (p,g for classic DH, normally the code for a standard curve for ECDH) plus server public key, plus a signature if ephemeral, and after at least one more message the client sends its public key, possibly but rarely followed by a signature. For classic DH the client either accepts the server's group or aborts; ... – dave_thompson_085 Jul 26 '16 at 4:51
  • ... for ECDH using standard curves it can use an extension in ClientHello to say which curve(s) it likes. (If the client only likes a curve(s) the server doesn't, the server aborts.) See rfcs 2246, 4346, and 5280 and (minor) modifications for ECDH in 4492. – dave_thompson_085 Jul 26 '16 at 4:52
  • I meant ECC in general. I'll fix this in my response. – Crypt32 Jul 26 '16 at 5:18
  • 1
    'In general' ECC can encrypt, but not in TLS, which is the question here. TLS uses ECC only for key agreement (ECDH, usually ephemeral but optionally fixed/static or 'anonymous' which is really ephemeral) and/or authentication (ECDSA). – dave_thompson_085 Jul 27 '16 at 4:07
  • Key encipherment is never used in TLS. – user207421 Mar 19 '17 at 17:10

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.