1

A certificate, in itself, (RFC 5280) does not seem to have any indicator of what algorithm was used (for example the argument to openssl req -newkey) to create the public and private keys ("Certificate Key Type"). That surprised me. A certificate has a "signature algorithm" field but that is the algorithm used by the CA to sign the certificate. Question 1: Is this observation correct? If so, why is the algo/key type of the certificate itself not in the certificate? After all its type too is required when used.

TLS 1.2 (RFC 5246). The Cipher Suite sent by the Client in the Client Hello has the Cipher Suite in the following form: TLS_part1_WITH_... I think only part1 is relevant to the derivation of the pre_master_secret. The part that follows the WITH is for securing the actual data. Question 2: Is this correct?

part1 is called "key exchange algorithm" (Section 7.4.1.2. Client Hello)
"The cipher suite... contains the combinations of cryptographic algorithms supported by the client in order of the client's preference (favorite choice first). Each cipher suite defines a key exchange algorithm..." . A Client Hello can have a "signature_algorithms" extension. "The client uses the "signature_algorithms" extension to indicate to the server which signature/hash algorithm pairs may be used in digital signatures." (Section 7.4.1.4.1.). For a key exchange, both algos, a signature and hash, are to be negotiated and if there is no signature_extension sent, then the hash is implied from the "key_exchange_algorithm" alone (7.4.1.4.1). So the implied hash algo is not based upon the type of Certificate.

Section 7.4.2. establishes some relations between the negotiated key_exchange_algorithms and the Certificate Type. The RFC lists a table with the two columns. One of the rows from the above mentioned table is:

  DHE_RSA            RSA public key; the certificate MUST allow the
  ECDHE_RSA          key to be used for signing (the
                     digitalSignature bit MUST be set if the key
                     usage extension is present) with the signature
                     scheme and hash algorithm that will be employed
                     in the server key exchange message.
                     Note: ECDHE_RSA is defined in [TLSECC].

Question 3: (Edited: Earlier mis-numbered it as Question 5). I think understanding this is the biggest hurdle for me. I understand the importance of Ephemerial keys (ECDHE vs. ECDH). The "RSA public key" refers to the key type in the certificate. Is that correct? Does the RSA in "DHE_RSA" and "ECDHE_RSA" also refer to the type of the key in the certificate? Is this key only used for authenticating the server? After all, ECDHE by itself, even without a certificate, can generate a common secret known only to the two parties but not to MiM. Can someone explain the role of the Certificate in the various stages of establishing the pre-master-secret?

1 Answer 1

3

First, this is a pretty broad question already. Please don't add anymore questions to this and ask for further details in new questions instead.

Question 1: Is this observation correct?

No. If you do a openssl x509 -text -in cert.pem you can see the public key and also the type of the public key:

    ...
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                00:be:f2:0e:d5:f5:97:8f:23:e1:89:6d:56:58:97:
    ...

Question 2: Is this correct?

Depending on the interpretation of what "securing the actual data" means. The part after the WITH in ciphers like TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 describes the method for encryption and integrity protection. It does neither describe the key exchange nor the authentication method. But without proper authentication and key exchange the key used in encryption could be compromised which means that it does not really "secure" the actual data.

Question 3: ...

You got this mostly right. The RSA/ECDSA in the cipher suite describes the authentication. And in case of ..DHE_RSA_.. or ..ECDHE_RSA.. it also only describes the authentication. There are ciphers like TLS_RSA_WITH_AES_128_CBC_SHA256 though where the key exchange algorithms is RSA and in this case the certificate is also involved in the key exchange.

Can someone explain the role of the Certificate in the various stages of establishing the pre-master-secret?

The certificate is only directly involved in the key exchange (i.e. establishing the pre-master-secret) in the obsolete RSA key exchange which essentially means that the client encrypts the pre-master-secret with the RSA public key and the server can decrypt it since it has the private key.

2
  • After posting the question, I came across this link where dave_thomson's answer addresses my last question and clarifies the specific doubts which I had. Other questions were answered in the answer accepted here.
    – asinix
    Commented Jan 26, 2020 at 17:46
  • Also this link though the title suggests a different topic than the questions asked here.
    – asinix
    Commented Jan 26, 2020 at 18:24

You must log in to answer this question.

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