2

Im studing about the tls handshake and I have some doubts.

After the client validate the digital certificate presented by the server the next step is the key exchange agreement using for example RSA to encrpyt and decrypt data exchanged during the tls session. In this RSA process the client generates a random number and uses the public key of the server to encrypt this generated random number and send this encrypted number to the server.

This random number is the pre-master secret. The server uses its private key to decrypt the pre master secret. From this pre-master secret the client and the server can generate the master secret that contanins the symetric key to use in the message encryption. This pre master secret, since it was encrypted using the public key of the server can only be decrpyed by the server with its private key. Doubt: Thus, because of this the security in the key exchange depends on the private key of the server right?

So, if the pre master secret is encrpyeed with the public key of the server, if an ataccker can get the private key its possible that the attacker can decrypt the information transmitted in the handshake and thus get access to the master key to decrypt data transmitted durring a session, wether it is data from an older or new session. Doubt: To fix this issue there is the concept of perfect forward secrecy right? If there is a guarantee that all information ecnrypted before the private key is compromise continues secure.

Doubt: And to use this perfect forward secrecy the ephemeral dh algorithm should be use right? To generate a new set of paramters dh for each session. My doubt about this is, in case of a site that uses https how do we know if it uses dh or ephemeral dh? And when to use dh or ephemeral dh in a https site?

Improve this question
1
  • Ephemeral DH or ECDH generates a new keypair (on each endpoint) for each session but not new parameters. DHE parameters (a large prime and the generator of a large prime-order subgroup of Zp*) are static and can be shared although people mostly don't. ECDHE parameters (a curve with base point, order and cofactor) are also static and in practice standardized (e.g. P-256 and P-384 from SECG+NIST) and thus everybody shares them. Draft TLS1.3 proposes to similarly standardize DHE parameters. TLS servers often allow you to configure DHE params and/or ECDHE curve(s).
    – dave_thompson_085
    Commented Oct 22, 2017 at 0:23

1 Answer 1

Reset to default
2

Your assumptions of how TLS works are mostly correct, i.e. the basic ideas are correct but some details (like how the pre-master-secret is generated) are wrong.

... in case of a site that uses https how do we know if it uses dh or ephemeral dh? And when to use dh or ephemeral dh in a https site?

Which authentication, type of key exchange, symmetric encryption and MAC is used is specified by the cipher. The client offers some ciphers and the server selects one of the offered ciphers. The ciphers which use ephemeral DH are the ones with DHE or ECDHE in their name, for example TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384. The ciphers which use non-ephemeral DH are the ones with only DH or ECDH in the name, like TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384.

Non-ephemeral DH requires that the static DH parameters (see TLS/SSL's usage of Non-Ephemeral DH vs DHE) are inside the certificate. This kind of certificate and therefore the kind of key exchange is very uncommon. If you check current browsers in SSLLabs client test you will see that none of these even offers DH/ECDH ciphers to the server but only DHE/ECDHE.

Improve this answer
1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .