Comprehensive Guide to RSA Algorithm in HTTPS Communication and Security

Introduction

Many web application layer protocols on the Internet have shifted from HTTP to HTTPS. HTTPS has increasingly replaced HTTP in numerous scenarios. Recently, due to business requirements, we conducted a packet capture analysis of HTTPS requests using Wireshark. Through this, we gained more insights into HTTPS, including the RSA algorithm, which we have organized to study together with everyone.

I. Overview

What exactly is HTTPS? In simple terms, HTTPS is an HTTP protocol with TLS/SSL encryption. The HTTP protocol transmits information in plain text, which poses risks of information eavesdropping, tampering, and impersonation. The TLS/SSL protocol provides functions such as information encryption, integrity verification, and identity authentication to prevent such issues.

The full name of TLS/SSL is Transport Layer Security, which is a security protocol between TCP and HTTP. It does not affect the existing TCP protocol and HTTP protocol, so using HTTPS generally does not require much modification of HTTP pages.

(Note: Most people associate HTTPS with SSL (Secure Sockets Layer), which was invented by Netscape in the mid-1990s. Over time, this statement has become less accurate. Since Netscape lost market share, it handed over the maintenance work of SSL to the Internet Engineering Task Force (IETF). The first post-Netscape version was renamed Transport Layer Security (TLS), with TLS 1.0 released in January 1999. Due to the 10-year history of TLS, the actual “SSL” transmission is almost invisible.)

II. TLS Handshake with Wireshark

Below is the establishment process of an HTTPS request from our packet capture data:

Clearly, the first three messages correspond to the three-way handshake process of TCP communication. (It should be noted that according to RFC2818, the appearance of “https” means that TCP needs to connect to port 443 of the target end.)

Client Hello

The TLS handshake process starts with this message.

• Version

We can see two Version pieces of information in the Client Hello message. According to RFC5246, they indicate: the first shows that the TLS version used for this communication is 1.0; the second shows the TLS version expected by the client is 1.2. (Note: In version negotiation, the client will provide the highest TLS version it can support, confirmed by the server for final use.)

• Random

The first four bytes are the current time, formatted as a Unix timestamp. It is followed by a 28-byte random number, which will be used in the following process.

• Session ID

It is null here. If the service was connected to a few seconds ago, it may continue the previous session without executing the entire “handshake” process again. In our packet capture content, since this is the first connection, the Session ID length is 0.

• Cipher Suites

This is a list of cipher algorithms supported by the request sender. The request initiator provides 22 options to choose from. We will have a more detailed introduction about CipherSuite later in the article.

• Extension: server name

This field contains the domain name information of the server we requested to be sent to. It functions similarly to the “Host” in the HTTP protocol header, allowing Internet companies to bind hundreds of websites to the same IP address for cost considerations.

ServerHello

It contains some key response information from the server to the Client Hello:

• Random

Similar to Client Hello, it returns the current time of the server and a 28-byte random number generated by the server.

• Version

The server confirms the TLS version for communication: TLS 1.2

• Cipher Suite

The encryption protocol suite used by the server for communication:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

• Session ID

The established session identification ID. With this, a subsequent reconnection to the server does not require a complete handshake process.

Certificate&Server Key Exchange&Server Hello Done

This message contains three parts: the server returns the certificate, exchanges the public key, and the “Server Hello” ends. After receiving the server certificate, the client will first verify its legitimacy. If the verification passes, subsequent communications will proceed.

Client Key Exchange&Change Cipher Spec, Encrypted Handshake Message(Finished)

These are three messages sent by the client: key exchange, code change notification, and handshake completion message. Change Cipher Spec, Multiple Handshake Messages(Finished)

This is the last message of the TLS handshake process, containing: server’s code change notification and handshake completion message. At this point, the entire TLS communication handshake process has been completed.

Note that the Finished message contains two parts: finish identifier and hash verification information. However, for both client and server, the content after Change Cipher Spec has been transmitted via encryption, so the specific content in Finished can no longer be viewed directly through Wireshark. The TLS communication process can be summarized as:

1. The client sends the supported TLS version, list of cipher suites, random numbers, etc., to the server through the Hello structure.
2. The server returns the selected TLS version, the encryption suite used, and the random number generated by the server to the client through the Hello structure. It will also send the certificate to the client, which contains a public key.
3. After verifying the certificate, the client generates a random number Pre-master secret, encrypts it with the certificate’s public key, and sends it to the server, while calculating the negotiated key.
4. The server uses the private key to decrypt the Pre-master secret and calculates the negotiated key.
5. Finally, both parties use the symmetric encryption key for decryption and transmission.

III. CipherSuite Introduction

After a basic understanding of the TLS communication process, let’s explore the concept of CipherSuite. Each CipherSuite is a combination of four algorithm types:

1. 1 authentication algorithm
2. 1 encryption algorithm
3. 1 message authentication code (MAC) algorithm
4. 1 key exchange algorithm

Clearly, these four algorithms are used to implement information encryption, integrity verification, and identity verification.

From our packet capture content, we can see that the encryption suite finally chosen by the server is:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Corresponding to CipherSuite algorithm types:

CipherSuite Algorithm Type	Example Corresponding Algorithm	Common Algorithm Name
Authentication Algorithm	RSA	RSA (Mainstream), DSA, ECDSA
Encryption Algorithm	AES_256_GCM	AES128/256 bit, encryption mode gcm/ cbc/ ecb RC4 and 3DES (Not Recommended), DES (Eliminated)
MAC Algorithm	SHA384	SHA256, SHA384, SHA1
Key Exchange Algorithm	ECDHE	DHE, ECDHE

(Note: Regarding the popularity trends of algorithms in cipher suites, interested readers can search on their own.)

About the CipherSuite negotiation process: The content of the HTTPS message is specified by the CipherSuite to indicate the algorithms used in the process. The server, in most cases, chooses from the client’s Cipher Suites in the order they are arranged from top to bottom, as algorithms positioned higher indicate higher security. Algorithm choice will somewhat affect the performance of the HTTPS connection. In some scenarios, the server can choose a more suitable algorithm combination by considering both security and efficiency issues.

IV. Some Mathematics-Related Knowledge

Symmetric Encryption and Asymmetric Encryption

Symmetric cipher coding technology has a characteristic that the same key is used for both file encryption and decryption, i.e., the encryption key can also be used as a decryption key. This method is called a symmetric encryption algorithm in cryptography. In a corresponding asymmetric encryption algorithm, two different keys are used for encryption and decryption. The public key is public, while the private key is held by the individual and must be kept secret.

In the communication process of HTTPS, asymmetric encryption is only used in the handshake phase, while the subsequent communication process uses symmetric encryption. Although asymmetric encryption is more secure compared to symmetric encryption, it also has two obvious drawbacks:

1. High CPU resource consumption: In a complete TLS handshake, the asymmetric decryption calculation during the key exchange accounts for over 90% of the entire handshake process. If application layer data also uses asymmetric encryption and decryption, the performance overhead would be too high to endure.
2. Asymmetric encryption algorithms have restrictions on the length of encrypted content, which cannot exceed the length of the public key. For example, the commonly used RSA public key length is 2048 bits, meaning that the content to be encrypted cannot exceed 256 bytes. Therefore, asymmetric encryption is currently only suitable for use in key exchange or content signing, not for encryption and decryption of application layer transmission content.

The asymmetric key exchange algorithm is the cornerstone of HTTPS’ security. Fully understanding the asymmetric key exchange algorithm is key to understanding the HTTPS protocol and functionality. Below, we introduce two common asymmetric algorithms:

Introduction to RSA Algorithm

In 1977, three mathematicians—Rivest, Shamir, and Adleman—designed an algorithm that implements asymmetric encryption. This algorithm, named after their three names, is called the RSA algorithm. Ever since then, the RSA algorithm has been the most widely used “asymmetric encryption algorithm.”

Generating Public and Private Keys

Assume Alice wants to receive a private message from Bob through an unreliable medium. She can generate a public key and a private key as follows:

Select two large prime numbers p and q, p not equal to q, and calculate N = pq.

According to Euler’s function, find r = φ(N) = φ(p)φ(q) = (p-1)(q-1)

Choose an integer e less than r, and calculate e’s modular inverse modulo r, called d. (A modular inverse exists if and only if e and r are coprime)

Destroy the records of p and q.

(N, e) is the public key, and (N, d) is the private key. Alice will transmit her public key (N, e) to Bob and keep her private key (N, d) secret.

Encrypting Messages

Assume Bob wants to send a message m to Alice. He knows Alice’s generated N and e. He first converts m into an integer n that is smaller than N and coprime with N using a format agreed upon with Alice. For example, he could convert each word into its Unicode code, then concatenate these numbers to form a single number. If his message is very long, he can divide it into segments and convert each segment into n. With the following formula, he can encrypt n to c:n^e ≡ c (mod N)

Calculating c is not complex. Once Bob computes c, he can transmit it to Alice.

Decrypting Messages

Once Alice receives Bob’s message c, she can decode it using her key d. She can convert the c to n using the following formula:

c^d ≡ n (mod N)

Once n is obtained, she can restore the original message m.

The decoding principle is

c^d ≡ n^(e·d)(mod N)

Given e·d ≡ 1 (mod r), i.e., e·d =1 +hφ(N). By Euler’s theorem:

n^(e·d) = n^(1 +hφ(N)) = n·((n^φ(N))^h)≡(n(1)^h)(modN) ≡ n (mod N)

Signing Messages

RSA can also be used to sign a message. Suppose Alice wants to send a signed message to Bob, then she can calculate a hash value (Message digest) for her message and encrypt this hash value with her private key, then attach this “signature” to the message. This message can be decrypted only with her public key. When Bob receives this message, he can use Alice’s public key to decrypt the hash value and then compare this data with the hash value he calculates for this message. If both match, then he can be sure the sender possesses Alice’s key and that the message was not tampered with along the transmission path.

Understanding RSA Better Through a Simple Practice

1. Assume p = 2, q = 5 (both p and q are prime numbers), then N = pq = 10;2. Find: r = (p-1)(q-1) = (2-1)(5-1) = 4;3. According to the modular inverse formula, e·d ≡ 1 (mod 4), i.e., e·d = 4n+1 (n is a positive integer);4. Assume n=5, so e·d = 21. Both e and d are positive integers and e is coprime with r; therefore, e = 7, d = 3;5. Obtaining the public key and private key: Public key (N, e) = (10, 7), Private key (N, d) = (10, 3);6. Assume the number to be transmitted is 2, encrypted with public key: (2^7)(mod 10) = 8;7. Decrypt with private key: (8^3)(mod 10) = 512(mod 10) = 2, thus obtaining the result;

ECDHE

Currently, most HTTPS traffic uses ECDHE for key exchange.

Before introducing ECDHE, let’s look at ECDH, which actually uses elliptic curve cryptography (ECC) in the DH key exchange (Diffie-Hellman) algorithm. The DH key exchange algorithm allows both parties to agree on a key without sharing any secrets. ECC is a cryptography system based on the discrete logarithm problem on elliptic curves, which offers higher security than RSA at equivalent key lengths.

ECDHE is the Ephemeral version of ECDH, which assigns a different DH key for each handshake process, thus providing forward secrecy. In fact, in HTTP/2, the allowed Cipher Suite must use a key exchange algorithm providing forward secrecy.

V. Conclusion

HTTPS essentially adds TLS/SSL between the TCP and HTTP layers to address security issues.

Before transmitting application data, TLS needs to negotiate the relevant parameters for secure communication through a handshake process.

Throughout the communication process, hash, symmetric encryption, asymmetric encryption, and certificates are mainly used to solve various security risk problems in client-server data transmission, thus ensuring the security of the entire communication process.