TLS 1.2 Handshake Overview

TLS 1.2 Handshake Overview

What is a TLS handshake

• TLS handshake is the process that kicks off a communication session that uses TLS encryption.
  • TLS is a security protocol designed to secure Internet communications.
• During a TLS handshake, it accomplishes 3 main things:
  • Negotiating cipher suites and parameters
  • Authenticating Peer (one or both parties)
  • Generating/exchanging symmetric session keys

First step: Negotiating cipher suites and parameters

Client start the negotiation first, by sending client’s offer, its supported parameters and algorithms. Then, server replying its preferences, chosen from the client’s offer.

Things that negotiated:

• TLS version: version of security protocol
• Cipher suite: A set of algorithms and parameters to build a secure channel for application data.
  • Example of TLS1.2 cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    • > Security protocol: TLS
    • > Key exchange algorithm: ECDHE
    • > Peer authentication algorithm: ECDSA
    • > Symmetric encryption algorithm: AES 128-bytes
    • > MAC Digest Algorithm (message integrity authentication): SHA256
• Compression: compression method.
  • Example: DEFLATE
• Extensions: extended capabilities
  • Example: server_name, ec_point_formats, renegotiation_info, application_layer_protocol_negotiation, status_request, session_ticket.

Second step: Authenticating Peer (one or both parties)

Depending on the peer authentication algorithm chosen in the cipher suite, server might need to provide a X.509 certificate for identity verification.

A non-anonymous server can optionally request a certificate from the client, if appropriate for the selected cipher suite.

Upon receiving, the client/server validate the signed-certificate to make sure the certificate is trustworthy.

Things that need to be checked:

• Check the strength of signature algorithm
  • Client application (web browser) has its own policy to reject weak algorithm
• Certificate’s integrity and Issuer/Signer Certificate check:
  • Step 1: Calculate the Current Hash-Value
    • > Calculate the hash value of the signed-certificate
    • > For this calculation, use the same hashing algorithm that was used during the signing process. (example: SHA256)
  • Step 2: Calculate the Original Hash-Value
    • > Decrypt the Digital Signature inside the certificate
    • > For this decryption algorithm, use the same encryption algorithm that was used during the signing process. (example: RSA)
    • > For the decryption key, use the public key of it’s Issuer/Signer
  • Step 3: Compare the Current and the Original Hash-Values
    • > Compare the current hash-value with the original hash-value
    • > If the two values are identical, the verification is successful
• Check if the Issuer Certificate can be trusted.
  • Normally for Public CA (Issuer), current client application (web browser) has trusted the Issuer (or the Issuer certificate has been installed inside the browser).
  • For Private CA (Issuer), the private organization need to manually trust the Issuer or by Windows GPO push.
• Check the certificate’s details
  • Server certificate’s common name or SAN (match with FQDN URL)
  • Issuer certificate’s common name
  • Certificate’s validity date
• Check the certificate’s revocation status
• Server identity authentication
  • Make sure the certificate’s sender (server) has the certificate’s private key
  • Client encrypt a value using server’s public key and the encrypted value as part of key exchange
    • > In RSA, client will send a RSA encrypted premaster secret
  • Server need to decrypt it using its private key and continue the key exchange the process
  • From this value, client and server will compute a session master key (symmetric key)
  • If both client and server ended up with the same session master key, authentication is successful.

Third step: Generating/exchanging symmetric session keys

The last part of the TLS handshake involves creating the (symmetric) “session master key,” which is the key that will actually be used for securing application data (HTTP).

• TLS handshake key exchange
  • The exact method for generating the key varies based on the cipher suite that was chosen, with the two most common schemes being RSA and Diffie-Hellman.
  • RSA
    • > The client generates a premaster secret (a 46-bytes random number), encrypts it with the server’s public key, and sends it in the ClientKeyExchange message.
    • > To obtain the premaster secret, the server only needs to decrypt the message.
  • DH
    • > To provide authentication, the server takes the client and server randoms, as well as the DH parameter that will be used to compute the session key, and encrypts them with its private key. This functions as the digital signature, the client will use the public key to verify the signature – and that the server is the rightful owner of the keypair – and respond with its own DH parameter
    • > Unlike RSA, there is no need for the client to send the pre-master secret to the server using asymmetric encryption, instead the client and server use the DH parameters they exchanged earlier to arrive at a pre-master secret. Then each uses the pre-master secret that it just calculated to mutually arrive at the session key.
• The Finish Message
  • To end the handshake, each party lets the other know they have done all the necessary work, then both run check-sums to make sure the handshake occurred without any malicious tampering or corruption.
  • The Finished message is the first protected message with the just negotiated algorithms, and master secret key (integrity check and encryption).
  • It includes a cryptographic checksum computed over all previous handshake messages (from both the client and server).
  • It obtains a proof that it has indeed talked to the same client all along.
  • Recipients of Finished messages MUST verify that the contents are correct.
• Once the SSL handshake is complete, the encrypted and authenticated application connection begins and all the data being sent and received between you and the server is protected.