0

This question is similar to this one, so let me elaborate what I'm struggling with.

I want to get the length/strength of the key used by the server during the key exchange and authentication, i.e. public key size for RSA, prime field size for DHE and so on.

So the way I understand it, the subject's public key and KeyUsage bits in the TLS certificate should be the values I'm looking at.

Now suppose the server has a TLS certificate with a RSA public key. Additionally the following KeyUsage bits are set:

keyEncipherment
digitalSignature

Furthermore let's assume the server only supports the cipher suites

TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256

In the case of the first cipher suite the key provided in the certificate can be used to exchange the bulk encryption key and authenticate the server.

My questions are:

  • What happens in the case of the second cipher suite?

    • Can the server return a different certificate chain, where the leaf certificate contains a different key?
    • Is the RSA key used to only sign the key exchange parameters?

  • What happens if the keyEncipherment (and/or digitalSignature) bit is not set?

    • Can I assume that it is always set in leaf certificates?

  • Is there a rule of thumb how to handle all the different combinations of key exchange and authentication algorithms?

schroeder
  • 123,438
  • 55
  • 284
  • 319
superuser
  • 3
  • 3

1 Answers1

0

Can the server return a different certificate chain, where the leaf certificate contains a different key?

Given that the first cipher suite requires an RSA public key and the second an ECC public key and that each certificate can contain only one public key the server must return a different certificate. This might or might not lead to different intermediate certificates or even a different root certificate too.

Is the RSA key used to only sign the key exchange parameters?

In TLS_RSA_WITH_CAMELLIA_128_CBC_SHA the key exchange is RSA too (not only the public key) which means that the client is using the servers pubkey to encrypt (not sign) the premaster secret.

What happens if the keyEncipherment (and/or digitalSignature) bit is not set?

It might fail, depending on the key exchange required by the cipher. See Which key usages are required by each key exchange method? for the details.

Is there a rule of thumb how to handle all the different combinations of key exchange and authentication algorithms?

I'm not sure what you expect, but obviously you need to have all the keyUsage in the certificate which are needed for the key exchange methods and the type of the public key must match the algorithms required by the ciphers. Usually client a server do not support all possible combinations anyway but only a subset.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • There's still one thing that bothers me: We want to do two operations key exchange and authentication with possibly two different methods and therefore different keys/parameters we need, but we are only getting one key/parameter from the certificate. How are we getting the other one? – superuser Sep 04 '19 at 08:57
  • @superuser: The parameters for the DHE/ECDHE key exchange are transferred inside the TLS handshake. These parameters are public and thus don't need to be encrypted - they need to be protected against modification by a man in the middle though. This protection is achieved since the whole handshake is protected by a signature based on the servers certificate. In this certificate is trusted to be not modified by MITM due to the authentication done before. – Steffen Ullrich Sep 04 '19 at 09:10