Key Exchange Method (eg. DHE, PSK or DHE+PSK), negotiated using the
Diffie-Hellman group used for the DHE (eg.
secp256r1, etc.), negociated using the
Signature schemes used for authentication (eg.
ecdsa_secp256r1_sha256), negotiated using the
Signature schemes accepted in certificates, negotiated using either the
signature_algorithms extension or the
Key Exchange methods
TLS v1.3 supports three key exchange methods:
- ephemeral Diffie-Hellman (combined with digital signatures for authentication);
- PSK with ephemeral Diffie-Hellman;
- PSK without ephemeral Diffie-Hellman.
The client announces that it intends to use one of the PSK methods by proposing one or several PSK identities to the server through the
pre_shared_key extension of the
ClientHello. In addition, it has to use the
psk_key_exchange_modes extensions as well in order to declare which of the two PSK methods it supports.
If the server accepts one of the proposed PSK identities, its answer includes the
pre_shared_key extension in the
ServerHello. This extension indicates which of the proposed PSK identities it has chosen to accept.
See the diagram in the TLS v1.3 specification.
If the client did not propose any PSK identity or if the server did not accept any of the proposed PSK identities, ephemeral Diffie-Hellman key exchange mode is used.
Note: in TLS v1.3, Diffie-Hellman covers both FFDH and ECDH. The group used for the Diffie-Hellman key agreement is negotiated using the
Signature algorithm for authentication
The signature algorithms used for authentication (
CertificateVerify messages) are negotiated using the
Signature algorithm for certificates
If the set of signature algorithms supported for the signatures embedded in the certificates is different, they are announced using the
Interpreting the output of ChromeDevTools
FFDHE_ECDSA, FFDHE_EdDSA, ECDHE_RSA, ECDHE_ECDSA, ECDHE_EdDSA
These key exchange algorithm names are not actually relevant in TLS v1.3 because the signature algorithm used for authentication is negotiated independently of the key exchange method and of the key exchange group.
TLS 1.3, X25519, and AES_128_GCM or
TLS 1.3, X25519, and CHACHA20_POLY1305
Which only tells me Curve25519 is picked.
X25519 is the group used for the Diffie-Hellman key exchange.
This can actually be seen in the details of ChromeDeveTools:
Key exchange group: X25519
As X25519 is an elliptic curve group, this mean you are using an ephemeral elliptic-curve Diffie-Hellman key exchange (ECDHE).
You (apparently) cannot directly see which signature algorithm has been used in ChromeDevTools but you can get some information by looking at the leaf certificate sent by the server. For example, when connecting to www.google.com, I get a certificate of type Elliptic Curve P-256. As a consequence, the signature scheme used is going to be
This is similar to ECDHE_ECDSA in TLS v1.2.