2

I am learning TLS handshake and find client/serve will negotiate a cihpersuite during client/server hello.

Usually, the last part of a ciphersuite is a hash algorithm, like SHA256 in ECDHE-ECDSA-AES128-SHA256. The second part of a ciphersuite is public key algorithm of server certificate like ECDSA. As we know, public key is usually capable of signing a message.

I also noticed in the client Hello, there is an extension called signature_algorithms to set the preferred hash/signature algorithm pairs. The chosen hash/signature is usually used to sign the Server Key Exchange.

My question is: since the ciphersuite already indicates both hash and signature algorithms, why we still needs the signature_algorithms extension?

Improve this question
1
  • 1
    It matters whether you are using TLS1.2 or 1.3. In 1.2 sigalgs (13) controls both the protocol-message signature (server must use algorithm specified in ciphersuite, but can choose hash) and signatures of certs in the chain; in 1.3 there are two extensions: sigalgscert (50) if present controls certs in chain, while sigalgs always controls protocol-message (which now is NOT constrained by the ciphersuite) and controls certs in chain IF sigalgscert is NOT present
    – dave_thompson_085
    Commented Jan 22, 2021 at 3:29

1 Answer 1

Reset to default
1

... since the ciphersuite already indicates both hash and signature algorithms

The hash given ciphersuite only defines the algorithms used for the integrity protection of the encrypted traffic, i.e. the HMAC. These are not for digital signatures. Similar the public key algorithm in the cipher suite is only about the public key of the server certificate used for authentication. It is not about public key of the client certificate nor about signatures used for the certificates.

Improve this answer
11
  • How does public key of server certificate is used for authentication? BTW, server seems to sign the Server Key Exchange record before sending to client. Which signature is used for the sign, the one from signature_algorithms or the public key from certificate?
    – Zachary
    Commented Jan 21, 2021 at 13:54
  • I used Wireshark to analyse TLS handshake. It seems that server does not send client the chosen signature algorithm, right?
    – Zachary
    Commented Jan 21, 2021 at 13:56
  • @Zachary: The public key of the certificate is used within authentication to check the signature done by the server using the matching private key. And there is no "agreeing" on signature algorithms, only announcing what is supported by the client. Whenever a signature is used by the server it is clear from the signature itself which algorithms were used.
    – Steffen Ullrich
    Commented Jan 21, 2021 at 14:10
  • 1
    Hash in 1.2 or lower ciphersuite controls the HMAC unless the cipher is AEAD (only in 1.2), and in 1.2 only also the 'PRF' (KDF) for new suites but not pre-1.2 ones; hash in 1.3 ciphersuite controls only the KDF because all ciphers are AEAD
    – dave_thompson_085
    Commented Jan 22, 2021 at 3:32
  • 1
    @Zachary: AEAD has builtin authentication; that's what 'Authenticated Encryption' means. It doesn't have to be HMAC and usually isn't; the AEAD ciphers (currently) defined for TLS are ChaCha20+Poly1305 and AES-GCM, which both use keyed polynomial-residue MACs, and AES-CCM, which uses CBC-MAC.
    – dave_thompson_085
    Commented Jan 22, 2021 at 23:39

You must log in to answer this question.

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