1

When using RSA for key exchange in TLS, the role of the public key embedded in the certificate is clear: for asymmetric encryption when sending the master key, which the server can decode using its private key.

However when doing diffie-hellman to generate a shared master, these public/private keys are no longer needed. So are they included in the certificate merely for legacy reasons (to support clients still using RSA for key exchange)?

  • 2
    There is a anonymous_DHE mode in TLS, but it is of questionable use as you know the connection is securely encrypted, but you can't be sure to whom you actually talk. – eckes Jun 6 '17 at 3:25
3

Before the key exchange is done the client has to ensure that it is talking to the correct server and not to some active man in the middle which could split the TLS connection into one between client and attacker and another between attacker and server. To authenticate the server the client is using the content of the certificate provided by the server, i.e. the subject and subject alternative names to validate the server name, the start and end time to check the life time and the signature to verify the trust chain to the builtin root CA.

The signature of the issuer of the certificate must be verified when building the trust chain which is done by using the known public key of the issuers CA certificate. Additionally it must be verified that the server is actually the owner of the certificate, i.e. knows the private key which only the owner should know. This is essentially done by the client providing input to a challenge which then gets signed by the server with the private key. This signature then can be validated by the client using the public key contained in the certificate and thus ownership of the certificate is verified. If client authentication is done using certificates a similar process is done for validating the client certificate.

  • I thought trust was established by means of checking whether the issuing authority is derived from a root CA? – 1110101001 Jun 6 '17 at 3:05
  • @1110101001: First: this check of building the trust chain requires the public key of this CA to verify the signature as described in my answer. Second: this check is not enough, one also needs to make sure that the server actually owns the certificate (which means has the private key) because otherwise some man in the middle could just present the servers certificate. – Steffen Ullrich Jun 6 '17 at 3:11
  • Ah that makes sense. So DH has to be combined with authentication by using RSA (or other asymmetric) for signing and verification. However, if you were to do straight RSA key exchange the authentication is implicitly built in since anyone who didn't have the private key couldn't decode the master key that was sent. – 1110101001 Jun 6 '17 at 3:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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