TLS handshake

TLS (Transport Layer Security) handshake is a process that occurs

between a client and a server when establishing a secure connection
over the internet. The handshake process involves several steps,
which I will explain below.

Here’s a simplified overview of the TLS handshake process:

1. The client initiates a TLS connection to the server by

sending a ClientHello message, which includes the TLS
version, a list of supported cipher suites, and a random
number.

2. The server receives the ClientHello message and responds

with a ServerHello message, which includes the selected
TLS version, the selected cipher suite, and another random
number.

3. The server sends its digital certificate, which includes its

public key, to the client.

4. The client verifies the server’s digital certificate using a

trusted Certificate Authority (CA) to ensure that the server
is who it claims to be.

5. The client generates a symmetric encryption key and

encrypts it with the server’s public key, which is included in
 the digital certificate. The client sends the encrypted key to
the server.

6. The server decrypts the symmetric encryption key using its

private key, which is known only to the server.

7. Both the client and server use the symmetric encryption

key to encrypt and decrypt all subsequent data transmitted
between them.

Here’s a more detailed explanation of the TLS handshake process:

1. The client initiates a TLS connection to the server by

sending a ClientHello message. The ClientHello message
includes the following information:

• The highest version of TLS that the client supports.

• A list of supported cipher suites, which are algorithms that

will be used for encryption.

• A random number, which is used to generate session keys

for encryption.

2. The server receives the ClientHello message and responds with a

ServerHello message. The ServerHello message includes the
following information:

• The selected version of TLS.

 • The selected cipher suite, which is chosen from the list of
supported cipher suites provided by the client.

• Another random number, which is used to generate session

keys for encryption.

3. The server sends its digital certificate to the client. The digital
certificate includes the following information:

• The server’s public key, which is used for encryption.

• The server’s name, which is used to verify that the client is

connecting to the correct server.

• The CA that issued the certificate, which the client uses to

verify that the certificate is valid.

4. The client verifies the server’s digital certificate. The client

performs the following checks:

• Verify the server’s name matches the hostname in the URL

or IP address used to connect to the server.

• Verify that the certificate is signed by a trusted CA.

• Verify that the certificate has not expired or been revoked.

5. If the server requires client authentication, it sends a

CertificateRequest message to the client. The CertificateRequest
message includes a list of acceptable client certificate types.
6. If the client has a valid certificate, it sends a Certificate message to
the server, which includes the client’s digital certificate.

7. The client generates a random pre-master secret, encrypts it with

the server’s public key, and sends it to the server in a
ClientKeyExchange message. The pre-master secret is used to
generate the session keys for encryption.

8. The server decrypts the pre-master secret using its private key,
and both the client and server use the pre-master secret to generate
the session keys for encryption.

9. The server sends a ServerHelloDone message to indicate that the

handshake is complete.

10. The client sends a ChangeCipherSpec message, which signals

that all subsequent messages will be encrypted using the session
keys.

11. The client sends a Finished message, which includes a hash of all
previous handshake messages, encrypted with the session keys.

12. The server sends a ChangeCipherSpec message and a Finished

message, which includes a hash of all previous handshake messages,
encrypted with the session keys.

At this point, the TLS handshake is complete, and the client and
server can begin transmitting encrypted data using the agreed-upon
session keys. The encryption ensures that any data transmitted
between the client and server cannot be intercepted or read by
unauthorized parties.

Throughout the TLS handshake process, both the client and server
perform several checks to ensure that the connection is secure and
the other party is who they claim to be. This helps to protect against
various types of attacks, such as man-in-the-middle attacks and
eavesdropping.

TLS is a critical component of internet security, and it is used by

many different applications and services, including web browsers,
email clients, and mobile apps. By using TLS, these applications can
ensure that data transmitted over the internet remains confidential
and secure.

In TLS, there are several key exchange algorithms that can be used
to securely exchange encryption keys between the client and server.
One of the most commonly used key exchange algorithms is the
Diffie-Hellman (DH) key exchange.

How Key Exchange works —

In simple terms, the DH key exchange algorithm works as follows:

1. The client and server agree on a large prime number and a

generator value.

2. The client and server each generate a secret number.

 3. The client and server use their secret numbers, along with
the agreed prime number and generator value, to
independently generate a public key.

4. The client and server exchange their public keys.

5. The client and server use their own secret number and the
other party’s public key to generate a shared secret key.

6. The client and server can then use the shared secret key to
encrypt and decrypt data transmitted between them.

The DH key exchange algorithm is designed to ensure that even if an

attacker intercepts the public keys exchanged between the client and
server, they cannot determine the shared secret key used to encrypt
and decrypt data. This is because the shared secret key is only
known by the client and server and is never transmitted over the
network.

TLS also supports other key exchange algorithms, such as RSA and
Elliptic Curve Cryptography (ECC), which work in different ways to
securely exchange encryption keys between the client and server.

Ace an Interview

Here’s an activity that kids can play to learn about key exchange
similar to TLS:

1. Divide the kids into pairs and have each pair choose a
secret number.
 2. Each kid should then multiply their secret number by a pre-
agreed prime number.

3. The resulting numbers are exchanged between the pairs of

kids.

4. Each kid then takes the number they received from their
partner and multiplies it by their original secret number.

5. The resulting number is their shared secret key, which they

can use to encrypt and decrypt messages between each
other.

To make the game more challenging, kids can try using different
prime numbers or using different operations (such as addition or
subtraction) to generate their shared secret key. The goal of the
game is to help kids understand the basic principles of key exchange
and how it can be used to securely transmit messages between two
parties.