IP/Network | ShareTechnote

TLS (Transport Layer Security) - HTTPS/SSL

TLS stands for Transport Layer Security and one of the Security Protocol that is most widely used these days. The most common application of TLS is HTTPS and SSL.

Transport Layer Security (TLS) is a cryptographic protocol used to provide secure communication over the internet based on Symmetric encryption algorithm. It is the successor to Secure Sockets Layer (SSL) and is used to establish a secure connection between a client (such as a web browser) and a server (such as a web server). TLS is used to encrypt data sent between the client and the server, preventing eavesdropping, tampering, and forgery.

TLS supports several versions, including TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3, with each version providing improvements in security and performance. TLS 1.3 is the latest and most secure version as of now (Mar 2023), and it includes several improvements over previous versions, such as a faster handshake, stronger encryption algorithms, and better support for forward secrecy.

TLS is used in a variety of applications, including web browsing, email, instant messaging, and virtual private networks (VPNs). When you visit a website that uses HTTPS, which stands for Hypertext Transfer Protocol Secure, you are using TLS to secure your connection. TLS is an essential tool for protecting sensitive data, such as passwords, financial information, and personal data, from interception and theft.

Handshaking

Transport Layer Security (TLS) is a cryptographic protocol used to provide secure communication over the internet. It is the successor to Secure Sockets Layer (SSL) and is used to establish a secure connection between a client (such as a web browser) and a server (such as a web server). TLS is used to encrypt data sent between the client and the server, preventing eavesdropping, tampering, and forgery.

During this handshake, the client and server exchange information about their capabilities, including the algorithms they support and any cryptographic keys they have. They also exchange digital certificates, which are used to authenticate each other's identity.

There are specific handshake procedure between client and server for this protocol. There are two types of handshake, full handshake and abbreviated handshake.

Full Handshaking

In a full handshake, both the client and server exchange their entire certificate chains and perform a full exchange of cryptographic parameters. This includes a Client Hello, Server Hello, Certificate, Server Key Exchange (optional), Certificate Request (optional), Server Hello Done, Client Key Exchange, Certificate Verify (optional), and Finished messages. This process is also known as a complete handshake.

The full handshake is used in the initial connection between the client and server, and it provides mutual authentication, key exchange, and the establishment of the session keys used for encryption and decryption of data. It is more secure than abbreviated handshaking since it ensures that both the client and server have all the necessary cryptographic parameters and certificates.

The full handshake defined in Fig1. of RFC 2246 (TLS v1.0) is as follows :

Client		Server
ClientHello	-------->
		ServerHello
		Certificate (Optional) ServerKeyExchange(Optional) CertificateRequest(Optional)
	<---------	ServerHelloDone
Certificate (Optional) ClientKeyExchange CertificateVerify(Optional) [ChangeCipherSpec]
Finished	-------->
		[ChangeCipherSpec]
	<---------	Finished
Application Data	<-------->	Application Data

Client Hello: The client initiates the handshake by sending a Client Hello message to the server, which includes information about the TLS version and cipher suites that the client supports.
Server Hello: The server responds with a Server Hello message, which includes the chosen TLS version and cipher suite.
Certificate: The server sends its digital certificate to the client, which includes its public key and identity information.
Client Key Exchange: The client generates a pre-master secret and encrypts it with the server's public key, which is obtained from the server's certificate. The client sends the encrypted pre-master secret to the server.
Server Key Exchange: If the chosen cipher suite requires it, the server sends its own key exchange message to the client.
Certificate Request: If the server requires the client to authenticate itself, it sends a Certificate Request message to the client.
Certificate Verify: If the client chooses to send a certificate, it sends a Certificate message, which includes its own digital certificate. The client then sends a Certificate Verify message, which includes a digital signature of the previous handshake messages, proving that it possesses the private key associated with the certificate.
Finished: Both the client and server calculate the session keys from the pre-master secret and other information exchanged during the handshake. The client sends a Finished message, which includes a hash of all previous handshake messages using the session keys. The server also calculates the session keys and sends a Finished message back to the client.

Abbreviated Handshaking

Abbreviated handshaking, also known as session resumption, is a faster way to establish a secure connection between the client and server after the initial full handshake. In abbreviated handshaking, the client uses the session ID from the previous connection to reconnect to the server without performing a full handshake.

The abbreviated handshake is faster than the full handshake since it skips the time-consuming cryptographic operations performed in the full handshake. However, it is less secure than the full handshake since it does not perform mutual authentication, which leaves the session open to potential attacks. Therefore, abbreviated handshaking is typically used for subsequent connections within a session, where the security risk is low

The abbreviated handshake defined in Fig2. of RFC 2246 (TLS v1.0) is as follows :

Client		Server
ClientHello	-------->
		ServerHello
		[ChangeCipherSpec]
	<---------	Finished
[ChangeCipherSpec]
Finished	-------->
Application Data	<-------->	Application Data

The client sends a Client Hello message to the server, including the session ID from the previous connection.
The server checks its cache to see if it has stored the session parameters associated with the session ID. If it finds a match, it sends a Server Hello Done message to the client, indicating that the session is resumed.
The client sends a Finished message to the server, which includes a hash of all previous handshake messages using the session keys from the previous connection.
The server sends a Finished message back to the client, which includes a hash of all previous handshake messages using the session keys from the previous connection.

Examples

Example 1 : https for log in

No	Direction	Message
1	Client ---> Server	Client Hello
2	Client <--- Server	Server Hello
3	Client <--- Server	Server Key Exchange, Server Hello Done
4	Client ---> Server	Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
5	Client <--- Server	New Session Ticket, Change Cipher Spec, Encrypted Handshake Message
6	Client <---> Server	< Application Data >

(1) Client Hello

TLSv1.2 Record Layer: Handshake Protocol: Client Hello

Content Type: Handshake (22)

Version: TLS 1.0 (0x0301)

Length: 512

Handshake Protocol: Client Hello

Handshake Type: Client Hello (1)

Length: 508

Version: TLS 1.2 (0x0303)

Random

GMT Unix Time: Jan 28, 1985 14:58:27.000000000 Eastern Standard Time

Random Bytes: b02f1094de53d13d338a8f1521377ba33b6311ead68d7b8e...

Session ID Length: 32

Session ID: d926e32f878f73c2f043ff69b1de33761dda2d2c103b307d...

Cipher Suites Length: 34

Cipher Suites (17 suites)

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)

Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)

Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc14)

Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13)

Cipher Suite: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc15)

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)

Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)

Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)

Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)

Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)

Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)

Compression Methods Length: 1

Compression Methods (1 method)

Compression Method: null (0)

Extensions Length: 401

Extension: server_name

Type: server_name (0x0000)

Length: 24

Server Name Indication extension

Server Name list length: 22

Server Name Type: host_name (0)

Server Name length: 19

Server Name: accounts.sharetechnote.com

Extension: Unknown 23

Type: Unknown (0x0017)

Length: 0

Data (0 bytes)

Extension: SessionTicket TLS

Type: SessionTicket TLS (0x0023)

Length: 228

Data (228 bytes)

Extension: signature_algorithms

Type: signature_algorithms (0x000d)

Length: 22

Signature Hash Algorithms Length: 20

Signature Hash Algorithms (10 algorithms)

Signature Hash Algorithm: 0x0601

Signature Hash Algorithm Hash: SHA512 (6)

Signature Hash Algorithm Signature: RSA (1)

Signature Hash Algorithm: 0x0603

Signature Hash Algorithm Hash: SHA512 (6)