Introduction: Why Do We Need HTTPS?

HTTP itself transmits everything in plaintext, which means anyone can easily intercept and read the traffic along the way. For example, an Internet Service Provider (ISP) or another intermediary could inject ads into web pages without the site owner’s approval.

HTTPS was created precisely to solve these security problems. It uses encryption to guarantee the confidentiality and integrity of data in transit. On one hand, it prevents pages from being maliciously tampered with; on the other, it protects users when they transmit sensitive data, such as logging into a bank account, checking email, or visiting a health insurance provider.

Without EncryptionThis is a string of text that is completely readableWith EncryptionITM0IRyiEhVpa6VnKyExMiEgNveroyWBPlgGyfkflYjDaaFf/Kn3bo3OfghBPDWo6AfSHlNtL8N7ITEwIXc1gU5X73xMsJormzzXlwOyrCs+9XCPk63Y+z0=

Below, we start from basic encryption concepts and work our way up to how HTTPS keeps data safe.

Encryption Basics

Depending on whether encryption and decryption use the same key, encryption techniques fall into two categories: symmetric encryption and asymmetric encryption.

Symmetric Encryption

Symmetric encryption is the most intuitive approach, like fitting a safe with a single key that both locks and unlocks it. Symmetric encryption generally performs well in speed, efficiency, and resource consumption; its main problem lies in key distribution and management.

• Alice and Bob share the same key .
• Alice encrypts message with key and sends the encrypted result to Bob.
• Bob decrypts the message with the same key , recovering the original message .

Asymmetric Encryption

Asymmetric encryption is also known as public-key cryptography. A web server generates a pair of mathematically related keys. Ciphertext produced by encrypting plaintext with the public key can only be decrypted with the corresponding private key. The public key is public, while the private key must be kept secret.

• Alice and Bob have never met and have no reliable communication channel, but Alice needs to send Bob a message over the insecure internet.
• Alice writes her message; at this point it is called the plaintext .
• Bob generates a key pair, using one as the public key and the other as the private key .
• Bob can send the public key to Alice by any means; it doesn’t matter even if an eavesdropper, Charlie, intercepts along the way.
• Alice encrypts the plaintext with the public key , producing the ciphertext .
• Alice can likewise send the ciphertext to Bob by any means; even if Charlie intercepts it, he cannot decrypt it.
• Upon receiving the ciphertext, Bob decrypts it with his private key , that is , recovering the plaintext that Alice wrote.
• Since Charlie does not have Bob’s private key , he cannot decrypt the ciphertext, and thus cannot learn the plaintext .
• If Alice loses her own original text , then without Bob’s private key she is in the same position as Charlie: unable to recover the original from the public key and the ciphertext .

Because asymmetric encryption is computationally expensive, it is usually combined with symmetric encryption: asymmetric encryption securely delivers a symmetric key, and then both parties use that symmetric key for efficient data encryption and decryption. Besides asymmetric encryption, key exchange can also be done by other methods, such as Diffie–Hellman key exchange, which lets both parties derive a shared key that only they can compute by exchanging some public information.

Digital Signatures and Certificates

Digital Signatures

In the real world, we prove identity with ID cards, signatures, fingerprints, and so on. In the digital world, digital signatures play a similar role. Their key properties include:

1. Unforgeable: only the signer can produce the signature.
2. Authentic: anyone can verify the signature’s validity with the public key.
3. Not Reusable: a signature cannot be reused for another message.
4. Unalterable: the signed message content cannot be tampered with.
5. Non-repudiation: the signer cannot deny having signed.

from cryptography.hazmat.primitives import hashesfrom cryptography.hazmat.primitives.asymmetric import dsa# Sender class, responsible for signing messagesclass Sender:    def __init__(self):        self.private_key = dsa.generate_private_key(key_size=2048)        self.public_key = self.private_key.public_key()    def sign_message(self, message: str) -> bytes:        # Compute the hash of the message        hasher = hashes.Hash(hashes.SHA256())        hasher.update(message.encode('utf-8'))        digest = hasher.finalize()        # Generate the digital signature with the private key        signature = self.private_key.sign(digest, hashes.SHA256())        return signature    def get_public_key(self):        # Return the public key for the receiver to verify with        return self.public_key# Receiver class, responsible for verifying message signaturesclass Receiver:    def __init__(self, public_key):        self.public_key = public_key    def verify_signature(self, message: str, signature: bytes):        # Compute the hash of the message        hasher = hashes.Hash(hashes.SHA256())        hasher.update(message.encode('utf-8'))        digest = hasher.finalize()        try:            # Verify the signature with the sender's public key            self.public_key.verify(signature, digest, hashes.SHA256())            print("Signature verified")        except Exception as e:            print(f"Signature verification failed: {e}")# Simulate message sending and signature verificationsender = Sender()receiver = Receiver(sender.get_public_key())message = "I am Nailong (Official)"# The sender signs the messagesignature = sender.sign_message(message)# The receiver verifies the signatureprint("Receiver starts verifying the signature...")receiver.verify_signature(message, signature)

Digital Certificates

A Certificate Authority (CA), acting as a trusted third party, has one core duty: verify a website’s identity and issue it a digital certificate, thereby solving the problem of trustworthy public key distribution.

Certificate Application and Issuance

The website owner generates a Certificate Signing Request (CSR). A CSR file typically contains the public key of the certificate to be issued, identifying information such as the domain name, and a digital signature that guarantees its authenticity and integrity.

The CSR is first sent to a Registration Authority (RA) for initial review. Once verified, the RA forwards the CSR to the CA. The CA signs the CSR with its own private key, ultimately generating and issuing the digital certificate to the applicant.

Certificate Chain Validation

As mentioned earlier, the receiver (such as a browser) needs the CA’s public key to verify the certificate’s signature. The natural solution is a secure mechanism for distributing the public keys of a set of trusted CAs to clients; in practice this is usually done by preinstalling them in the operating system/browser.

On Windows, for example, they are installed in the Trusted Root Certification Authorities certificate store. See Trusted Root Certification Authorities Certificate Store - Windows drivers | Microsoft Learn for steps to access these certificates.

This way, the various Intermediate Certificates signed by a Root CA are considered trustworthy, and by the same reasoning, server certificates signed by those intermediates are trusted as well.

Take the Bank of China’s official site as an example. There are three certificates, and the certificate for www.boc.cn is signed by DigiCert CA1.

Step 1: Verify the End-Entity Certificate

1. Receive the certificate: the browser receives the www.boc.cn certificate from the Bank of China server. Inspecting it, the browser finds the issuer is DigiCert ... CA-1.
2. Verify the signature: to confirm the certificate’s authenticity, the browser needs to find the certificate of DigiCert ... CA-1 and extract its public key, then use that public key to decrypt and verify the digital signature on the www.boc.cn certificate.

Step 2: Verify the Intermediate Certificate

1. Trace upward: after successfully verifying the end-entity certificate, the browser must verify the legitimacy of the intermediate certificate DigiCert ... CA-1 itself. It finds that this certificate’s issuer is DigiCert Global Root CA.
2. Verify the root certificate: the browser looks up the public key of DigiCert Global Root CA in the Trusted Root Certification Authorities certificate store and uses it to verify the certificate’s authenticity.

Through this level-by-level upward verification, the browser ultimately confirms that the identity of www.boc.cn is trustworthy.

The SSL/TLS Handshake

Technically speaking, HTTPS is not a new protocol independent of HTTP. It is essentially “HTTP over TLS/SSL”: HTTP with encrypted transport provided by TLS/SSL.

The TLS handshake happens after the TCP three-way handshake, and its core goals are:

• Negotiate the version: determine which TLS version both sides will use (e.g. TLS 1.2, 1.3).
• Negotiate cipher suites: determine the combination of cryptographic algorithms (Cipher Suites) to use.
• Authenticate the server: the client confirms the server’s identity by verifying its digital certificate.
• Generate the session key: securely generate a symmetric key (the session key) for efficient encryption of subsequent communication.

The exact steps of the TLS handshake vary with the chosen key exchange algorithm and cipher suite. For a deeper dive, see What happens in a TLS handshake? | Cloudflare.

References

• What is HTTPS? | Cloudflare
• What happens in a TLS handshake? | SSL handshake | Cloudflare
• 【信息保护论】Ch9. 防止抵赖：数字签名-CSDN 博客