The Role of DNS Middleman in HTTPS Security: Preventing Man-in-the-Middle Attacks

Your connection to the server passes through an intermediary. While you assume you’re transmitting data securely to the server, it actually goes through a middleman, who can intercept or alter your data before forwarding it to the server. Likewise, they can modify the server’s data before sending it to you. The middleman remains invisible to you, so you are unaware that your data might be intercepted or modified.

II. Methods of Man-in-the-Middle Attacks

The common methods include the following:

1) DNS Spoofing

When accessing a domain, you need to resolve it first, i.e., request the DNS server for the IP address of a domain. For example, the IP address I resolved for taobao.com is:

A DNS middleman might respond with a false IP address leading to the attacker’s machine.

2) ARP Spoofing

While IP addresses are used for WAN transmission, physical addresses are used within a LAN. For instance, a router requires knowing the physical address of connecting devices to send packets. It uses an ARP broadcast to query devices about the physical address of a given IP. For example:

The router broadcasts asking for the physical address of 192.168.1.100. Since no one responds, it keeps broadcasting every second. As all devices in the network receive this packet, it can be used to deceive the router:

The address 192.168.1.102 responds to the router with its physical address.

III. HTTPS as the Only Defense Against Man-in-the-Middle Attacks

In the SSL source code, there’s a comment:

1234	/* cert is OK. This is the client side of an SSL connection. * Now check the name field in the cert against the desired hostname. * NB: This is our only defense against Man-In-The-Middle (MITM) attacks! */

The last sentence means that HTTPS is the sole defense against man-in-the-middle attacks. To understand why, we need to look at how the HTTPS connection process works.

IV. The HTTPS Connection Process

For non-experts, it can be explained like this:

In an HTTPS connection, the server sends its certificate to the browser (client), which then verifies the certificate and checks if the hostname matches. If it does, both parties encrypt the data before transmission and decrypt upon receipt, ensuring the data remains opaque.

But a smart layperson might ask how the browser verifies the certificate, what exactly a certificate is, and whether encryption can resist MITM decryption?

First, what exactly is a certificate? You can see its contents in the browser, for instance by accessing Google and clicking the lock icon in the address bar:

Click on details -> view certificate to see the complete content:

Next, we use a packet capture tool like WireShark to intercept the entire HTTPS connection and analyze the contents of these packets.

Using Taobao as an example, when you open Taobao, you can see its IP address in Chrome:

Then open WireShark, set the filter criteria to ensure both source and destination IPs match, and you can observe the entire connection establishment:

The first step is to establish a TCP connection; from there, we start discussing from the Client Hello:

1. Client Hello

In WireShark, observe the client hello and enumerate important information sent by the client to the server:

(1) The TLS version used is 1.2. TLS has three versions: 1.0, 1.1, and 1.2, with 1.2 being the latest. HTTPS encryption relies on the TLS transport layer security protocol:

(2) The current time and a random password string from the client. The time is measured in seconds since the Unix epoch (1970.01.01), here indicated as 147895117; the role of the random number will be discussed later.

(3) SessionId, the session ID, is 0 for the first connection. If it has a session ID, it can resume the session and avoid repeating the handshake process:

(4) The encryption suites supported by the browser: the list shows the browser supports 22 different suites, letting the server choose one. The specific encryption method will be introduced later.

(5) There’s also something interesting: the domain name:

This is unusual because the domain name operates at the application layer (http), while the handshake occurs at the transport layer (TLS). Information about the domain name is given to the server at the transport layer so the server can send the corresponding certificate based on the domain name.

Essentially, https = http + tls, as depicted in the figure below:

The data is transmitted using HTTP, while encryption relies on TLS. What is the relationship between TLS and SSL? SSL is the predecessor of TLS; after SSL was deprecated, TLS 1.0, 1.1, and 1.2 were developed.

3. Server Hello

After receiving the Client Hello information, the server sends a Server Hello packet to the browser containing similar messages:

(1) Time, random number, etc. Note that the server also sends a Session ID to the browser.

(2) The encryption method chosen by the server: among the methods supported by the client, the server selects the following, which is also one of the most popular methods currently:

4. Certificate

The server then sends a certificate packet:

Expand the certificate in WireShark:

In total, the server sends three certificates. The first certificate is named *.tmall.com, the second is GlobalSign Org., and the third is GlobalSign Root. What is the relationship between these three certificates? They’re interdependent. In the browser, this relationship is clear:

The tmall certificate depends on the GlobalSign Org certificate, meaning GlobalSign Org certifies the validity of tmall’s certificate, while the GlobalSign Root certifies the GlobalSign Org, forming a chain of trust. Understanding this is crucial. From a technical standpoint, if GlobalSign signs the tmall certificate correctly, it verifies the tmall certificate’s legitimacy.

Within the tmall certificate, its superior certificate is identified:

Now, let’s examine the certificate content more closely.

Aside from the signature mentioned earlier, each certificate contains the signature algorithm and the to be signed certificate (tbsCertificate):

What’s inside the tbsCertificate? In WireShark, you can see the information filled during certificate application, such as country, state, city, and organization name:

Domains supported by the certificate, where you see taobao listed:

Certificate validity, showing that the certificate will expire at the end of the year if not renewed:

The public key of the certificate, with the public key of GlobalSign Org being:

We could extract the public key from the certificate, which consists of 270 bytes in hexadecimal form:

String publicKey = “3082010a0282010100c70e6c3f23937fcc70a59d20c30e533f7ec04ec29849ca47d523ef03348574c8a3022e465c0b7dc9889d4f8bf0f89c6c8c5535dbbff2b3eafbe356e74a46d91322ca36d59bc1a8e3964393f20cbce6f9e6e899c86348787f5736691a191d5ad1d47dc29cd47fe18012ae7aea88ea57d8ca0a0a3a1249a262197a0d24f737ebb473927b05239b12b5ceeb29dfa41402b901a5d4a69c436488def87efee3f51ee5fedca3a8e46631d94c25e918b9895909aee99d1c6d370f4a1e352028e2afd4218b01c445ad6e2b63ab926b610a4d20ed73ba7ccefe16b5db9f80f0d68b6cd908794a4f7865da92bcbe35f9b3c4f927804eff9652e60220e10773e95d2bbdb2f10203010001”;

This public key comprises N and e components:

1	publicKey = (N, e)

N is a large integer derived from the product of two prime numbers:

1	N = p * q

e is an exponent, pertaining to an asymmetric encryption algorithm contrasting symmetric encryption, which is where the same encryption and decryption method is used on both ends requiring pre-transmission of a method or key. In asymmetric encryption, the encryption uses a key, while the decryption uses a public key, which is openly available, while the key remains secret.

The first asymmetric encryption algorithm was the Diffie-Hellman Algorithm, invented by Diffie and Hellman. Later in 1977, MIT’s Rivest, Shamir, and Adleman developed a new algorithm named RSA. The advantages include:

Encryption and decryption calculations are very simple.
Breaking the encryption is extremely difficult given a sufficiently large key.

RSA is fundamental to any computer network. How does RSA encryption/decryption work?

5. RSA Encryption and Decryption

Suppose we’re sending “Hello.” The ASCII encoding is: 104 101 108 108 111, forming the message:

M = 1041010108108111

The ASCII/Unicode-encoded text undergoes encryption:

EM = M^e % N

Here, M is raised to the power of e, divided by N to get the remainder, generating EM, the encrypted message. N and e compose the public key. The receiver decrypts EM using their private key:

M = EM^d % N

The encrypted data is raised to the power of d, divided by N to get the remainder where (N, d) represent the private key. This method ensures decryption for those with the corresponding private key. Breaking the key is exceptionally challenging as previously stated.

Returning to the certificate’s public key: this number is divided into two parts, N and e:

Gray numbers are markers. N is a massive 512-digit hex number, equivalent to 2048 bits in binary. Ordinary certificates use 1024 bits, and 2048 is highly secure. In decimal form, it’s a 617-digit number. If one could decompose this number into two primes, you would decipher GlobalSign’s private key and effectively bypass the security of GlobalSign’s certificate, though this is improbable.

The typical exponent, e, is 65537, a common choice in certificates.

The certificate uses the encryption algorithm RSA + SHA256, a hash algorithm verifying certificate integrity:

We extract the encrypted value as the certificate’s signature:

String sinature = “3ec0c71903a19be74dca101a01347ac1464c97e6e5be6d3c6677d599938a13b0db7faf2603660d4aec7056c53381b5d24c2bc0217eb78fb734874714025a0f99259c5b765c26cacff0b3c20adc9b57ea7ca63ae6a2c990837473f72c19b1d29ec575f7d7f34041a2eb744ded2dff4a2e2181979dc12f1e7511464d23d1a40b82a683df4a64d84599df0ac5999abb8946d36481cf3159b6f1e07155cf0e8125b17aba962f642e0817a896fd6c83e9e7a9aeaebfcc4adaae4df834cfeebbc95342a731f7252caa2a97796b148fd35a336476b6c23feef94d012dbfe310da3ea372043d1a396580efa7201f0f405401dff00ecd86e0dcd2f0d824b596175cb07b3d”;

This 256-byte signature is what GlobalSign Org achieved using its private key on tbsCertificate, then decrypting it using GlobalSign Org’s public key, as follows:

12345678	String decode = new BigInteger(signature, 16) //convert to a large number.pow(e) //raise to the e power.mod(new BigInteger(N) ) //mod N.toString(); System.out.println(decode);

Note that in actual computations, instead of directly raising to the power e, which yields an astronomical number, calculations must modulate after each multiplication, simplifying it substantially. The computed result would be:

This result can be broken down into segments:

The first byte is 00, which must always be smaller than other bytes. The second byte, 01, indicates a private key operation. The ff-values serve as padding to extend the signature length, increasing the difficulty of cracking. The last 64 bytes represent the SHA hash. If the certificate hasn’t been tampered with, hashing tbsCertificate yields a value identical to the signature, assuring its integrity. Let us manually compute the hash of tbsCertificate and compare it with the hash in the signature.

The computation method is as follows:

hash = SHA_256(DER(tbsCertificate))

Note that this isn’t a direct hash of tbsCertificate; rather, its DER encoded value is hashed. DER is an encoding standard; the certificate DER value can be exported from WireShark, already DER-encoded upon transmission:

Then, leverage OpenSSL for hash calculation, utilizing the following command:

openssl dgst -sha256 ~/tbsCertificate.bin

The computation result is:

Signifying:

bedfc063c41b62e0438bc8c0fff669de1926b5accfb487bf3fa98b8ff216d650

Corroborated against the hash in the signature (displayed in green below):

Verification confirms correctness! This confirms that the certificate for tmall has not been tampered with, and is indeed tmall’s official certificate. So, could an attacker both modify the certificate and ensure a correct hash value? It’s rare for different strings to produce the same SHA256 hash. Furthermore, since the key and public key must be paired, an attacker might switch only the public key (a product of p * q), encountering severe difficulty in devising a meaningful public key with the same hash as the original, making such attempts impractical.

Thus, we can trust that only an individual with access to GlobalSign Org’s private key could correctly encrypt this certificate. Therefore, tmall’s certificate is verifiably issued and signed by GlobalSign. Using similar checks, GlobalSign Org can prove itself signed by GlobalSign Root. But why trust GlobalSign?

In case the MITM doesn’t alter but entirely replaces the certificate with their own (named HackSign) inserting a domain like *.taobao.com. What’s the difference between HackSign and GlobalSign, and why trust GlobalSign over HackSign?

GlobalSign Root is built into the browser or OS and is visible in Firefox’s certificate list:

GlobalSign Root is built-in—this means we intrinsically trust GlobalSign Root. Having verified GlobalSign Org’s signature is valid, we can trust the propriety of tmall’s GlobalSign Org certificate. Thus, the trust chain extends from GlobalSign Root to tmall. Additionally, certificate authorities pre-register domain names such as *.taobao.com, precluding others from reusing these domain names for certificate registration.

This explains the necessity for certificate purchasing and validity periods.

You may now question if, unable to modify or replace a certificate, one can clone it and place it on their server, as the certificate contents are easily viewable in browsers and WireShark. By redirecting domain traffic using domain poisoning, your cloned certificate appears legitimate. Does this invalidate a certificate’s usefulness?

This query intrigued me for a long time then it becomes simple once you grasp the process. As both entities exchange RSA public keys, the paired set of public and private keys is unique. Even if a certificate is cloned, without knowing the private key, interception renders transmitted data undecodable, hence invalidating the purpose of certificate theft.

This makes sense why identity verification via certificates is feasible.

How long does this connection process take?

IV. The Cost of Using HTTPS

Packet timestamps in WireShark reveal:

From Client Hello at 4.99s to the Change Cipher Spec packet at 5.299 seconds, the HTTPS connection process takes 0.3s. Thus, adopting HTTPS incurs certain costs:

HTTPS establishment duration (~0.3s)
Encryption and decryption consume more CPU resources.
Encrypted data enlarges message size, requiring more bandwidth.

V. Bypassing HTTPS

Use SSLstrip: this tool employs ARP spoofing, forcing users to HTTP when attempting HTTPS. Consequently, the MITM and the server connection remain secure with HTTPS. To avoid this issue, note whether frequently visited HTTPS sites suddenly revert to HTTP, indicated by the lock icon disappearing from the browser address bar:

VI. Creating a Self-Signed Certificate

Certificates can be purchased or self-created via OpenSSL. Generate a certificate with:

openssl req -x509 -nodes -sha256 -days 365 -newkey rsa:2048 -keyout test.com.key -out test.com.crt

The example, employing sha256 + rsa 2048-bit encryption and a 365-day validity, produces a certificate (test.com.crt) and key (test.com.key). During generation, relevant information will be requested:

You’ll get two files: a non-signed certificate and a private key:

Adding the certificate to the browser, marking it as trusted, avoids the NET::ERR_CERT_AUTHORITY_INVALID error, enabling its use without issues.

This article draws inspiration from another blog: “What Happens in the First Few Milliseconds of an HTTPS Connection” written in 2009, though some parts seem outdated and certain critical aspects insufficiently explained. The detailed study conducted by the author made the above explanations possible.

Unicorn Network Threat Analyzer