6

When it comes to a secure TLS configuration (e.g. for HTTPS), the topic is prominently about the supported cipher suites.

I want to fully understand which part of the cipher suite has which role in a SSL/TLS connection.

So from what I understand it generally works like this:

  1. Client connects to the server
  2. Client tells server about their supported protocol (e.g. TLS 1.2) AND the cipher suite (e.g. ECDHE-RSA-AES128-GCM-SHA256)
  3. Server answers and agrees on a protocol and cipher suite they both support (e.g. TLS 1.2 & ECDHE-RSA-AES128-GCM-SHA256), as well as the servers certificate (also containing their public key)

--- now from here on they communicate based on the chosen protocol and the role of the cipher suite becomes important ---

  1. The client verifies the server's certificate against known certificate authorities and extracts the server's public key for the key exchange

  2. Now the cipher suite's key exchange kicks in (in this case ECDHE-RSA), which uses the server's public key - the result is the pre-master secret (as depicted in the diagram below)

  3. With the pre-master secret, both the cipher and the hashing algorithm are then used (in this case AES128-GCM and SHA256) for the message encryption and digests.

  4. The key exchange is repeated, encrypted with the cipher, using the pre-shared secret and verified with the hashing algorithm. The result is the master secret

  5. The master secret is used with the cipher and hashing algorithm, to encrypt any further communication.

SSL/TLS handshake(Diagram from: https://blogs.msdn.microsoft.com/kaushal/2013/08/02/ssl-handshake-and-https-bindings-on-iis/)

Is my understanding of the ciphersuite's role in a TLS communication correct - or am I wrong on some details?

SaAtomic
  • 1,009
  • 2
  • 17
  • 28

2 Answers2

6

So from what I understand it generally works like this:

  1. Client connects to the server

For HTTPS yes. For other applications it varies; some make a new connection and some reuse an existing connection.

  1. Client tells server about their supported protocol (e.g. TLS 1.2) AND the cipher suite (e.g. ECDHE-RSA-AES128-GCM-SHA256)

Ciphersuites plural, and quite a few other things in extensions, both shown in the article you link. (Which highlights SNI as relevant to the IIS/http.sys logic being described.)

  1. Server answers and agrees on a protocol and cipher suite they both support (e.g. TLS 1.2 & ECDHE-RSA-AES128-GCM-SHA256), as well as the servers certificate (also containing their public key)

The certificate contains the static (long-term) public key, and as ISMSDEV said is accompanied by any intermediate aka chain certs, and optionally the root cert. The article doesn't clearly state, but does show in the network trace, that the certificate(s) are actually a separate message but possibly in the same SSL/TLS record and almost always in the same TCP frames. For ephemeral keyexchange, as in the ciphersuite you specified but not the one in the article, the server's ephemeral key (with parameter(s) and signature much as ISMSDEV said) is in a separate message ServerKeyExchange; then optionally another message to 'Request' a client certificate, again not clearly stated and this time not shown; then a ServerHelloDone message, not described at all but shown.

--- now from here on they communicate based on the chosen protocol and the role of the cipher suite becomes important ---

The protocol version/format and key-exchange have already affected the server messages above. The symmetric cipher and possibly hash don't have effect yet.

  1. The client verifies the server's certificate against known certificate authorities and extracts the server's public key for the key exchange

Verifies the certificate chain, extracts the longterm (certified) key and also extracts and verifies the ephemeral key if used, which it is in the ciphersuite you specified.

  1. Now the cipher suite's key exchange kicks in (in this case ECDHE-RSA), which uses the server's public key - the result is the pre-master secret (as depicted in the diagram below)

Key-exchange has already started, with the server messages above; it is now completed using the client's key. The diagram you copy shows an arrow from client to server with (encrypted) pre-master secret because it is for a ciphersuite using RSA key-exchange, but you specified a ciphersuite using ECDHE-RSA key-exchange and for that the client's ephemeral publickey is sent (in clear) instead and the ECDH algorithm is used, independently at both peers, to derive the pre-master secret.

In addition if client certificate (aka client authentication) was requested, the client may send its own cert chain and its signature on a transcript through the client's key exchange message, (both) as separate messages, as described in the article but not shown.

  1. With the pre-master secret, both the cipher and the hashing algorithm are then used (in this case AES128-GCM and SHA256) for the message encryption and digests.

Not yet.

  1. The key exchange is repeated, encrypted with the cipher, using the pre-shared secret and verified with the hashing algorithm. The result is the master secret

Nothing is repeated, and nothing directly uses the pre-master secret. Instead the pre-master secret is used with the 'random' (nonce) values from the Hello messages in an algorithm called the PRF (Pseudo-Random Function) to derive the master secret, and then the master secret is similarly used to derive several session keys. As the article says:

[the server] performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret. (bullet) Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity [....]

Note the plural in 'session keys'. For some ciphersuites in TLS1.2, including the one you specified, the hash in the ciphersuite affects the PRF. For other ciphersuites, and all lower protocol versions, it does not. See What's the hash for in ECDHE-RSA-AES-GCM-SHA? .

  1. The master secret is used with the cipher and hashing algorithm, to encrypt any further communication.

Each endpoint sends a message ChangeCipherSpec to 'activate' the ciphersuite and then a message Finished, which is the first encrypted (and MACed) message. As the article says:

The CLIENT & the SERVER send each other a message informing that future messages from them will be encrypted with the session key. It then sends a separate (encrypted) message indicating that its portion of the handshake is finished.

Nothing directly uses the master key. Symmetric (data) encryption uses two of the session keys (one for each direction). For ciphersuites that use HMAC for integrity (as in the article), it uses the hash algorithm from the ciphersuite (and two more session keys), but you specified a ciphersuite which uses GCM mode, which as ISMSDEV said provides its own authentication (not using any hash).

Community
  • 1
dave_thompson_085
  • 10,064
  • 1
  • 26
  • 29
1

I think you are on the correct lines. My understanding of the protocol regarding the cipher suites impact on the protocol is as such.

client hello

Contains the highest version of SSL/TLS version the client supports, a random nonce generated by the client, a session ID (initial handshake will be zerod out), a list of possible cipher suites (see below) the client supports (these contain the authentication algorithm to use, encryption algorithm to use, and key agreement protocol)

Client now awaits a response from the server...

server hello

Contains the highest version of SSL/TLS that the server supports that the client supports, a random nonce generated by the server, the session ID provided by the client or a new session id if none supplied by the client. The server chooses which cipher suite to use, for example:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

which breaks down as:

- Protocol - TLS

- Key exchange algorithm - ECDHE_RSA - Elliptic Curve Diffie-Hellman Ephemeral with RSA. How the client will agree on the symmetric keys.

-Encryption algorithm - AES_128_GCM - The algorithm used for encrypting the payload data with the keys agreed. AES 128 (Advanced Encryption Standard with a key length of 128 bits) and using the block mode GCM (Galois/Counter Mode), which also provides message authentication to the encrypted data.

- Pseudorandom function - SHA256 - The type of algorithm used for the generation of the master secret, which is used to seed the creation of session keys. In this cipher suite it is using the well known SHA256 hash algorithm to offer high levels of entropy. certificate

This message contains the certificate used to sign the servers public key and any intermediate certificates in the X509 certificate chain.

server key exchange

Using the key agreement protocol from the cipher suite the server sends any elements it needs to the client. Example, for Ephemeral Diffie-Hellman this would be 3 parameters plus a signature on those parameters. The parameters are the two global DH parameters plus the servers DH public key.

Bruno Rohée
  • 5,351
  • 28
  • 39
ISMSDEV
  • 3,272
  • 12
  • 22
  • 1
    Ephemeral DH uses two global parameters (p,g) and one number for public key (y or more specifically y_s), but ephemeral ECDH as in the Q almost always uses one global parameter (an id from the registry) and a public point (which is a single value but contains at least in abstract two coordinates). – dave_thompson_085 May 26 '17 at 11:18