Stanford CS144 Computer Networks Podcast: Key Concepts and Methods of Network Security TLS/HTTPS

In this article, we'll start with the four core attributes of network security, gradually delve into common threat models, a powerful cryptographic toolbox, and a trust-enhancing certificate system. Finally, we'll connect the dots by analyzing the TLS/HTTPS protocol.

Laying the foundation for security: Four core attributes of network security

The design of any security system is inseparable from four basic goals, which are the cornerstones of evaluating system security.

• Confidentiality  : Ensures that information is accessible and understood only by authorized entities. In layman's terms, this means "those who shouldn't be able to see it can't understand it." Even if an attacker eavesdrops on your communications, they won't be able to decipher the true content. The primary technology for achieving confidentiality is  encryption  . An interesting application is opportunistic encryption, which uses encryption even when the identities of the communicating parties are not strictly authenticated. Its primary purpose is to prevent large-scale, non-targeted network surveillance.
• Integrity  : Ensures that data has not been tampered with or corrupted without authorization during transmission or storage. This means that the data you receive must be exactly the same as the data your friend sent, not a single bit different. It's important to note that encryption alone only ensures confidentiality; it doesn't prevent attackers from modifying ciphertext. In many scenarios, integrity takes precedence over confidentiality.
• Authenticity  : Verifying that the parties involved in a communication are who they claim to be. Simply put, it means "confirming that the person you are chatting with is who you think they are." Authenticity is a prerequisite for establishing secure communications. You must first verify the other party's identity before you can confidently send them confidential information.  Certificates  are a key technology for achieving authenticity.
• Availability  : Ensures that authorized users can access and use network services and resources when needed. This attribute is primarily used to combat denial-of-service attacks and other attacks designed to paralyze services.

Know Yourself and Know Your Enemy: Understanding the Threats We Face

Threats in the cyber world are diverse and can be broadly categorized into two types: accidental sabotage and deliberate adversarial attacks.

Accidental Corruption

This type of threat is not malicious, but rather  bugdata corruption caused by hardware failure, software, channel noise, etc. The familiar  IP header checksum, TCP/ UDP checksum, and Ethernet frame check sequence (FCS) are mainly used to detect such unexpected errors.

Adversarial Attacks

This is our focus, referring to malicious actions initiated by attackers to undermine the security properties of the system.

Eavesdropping

Attackers passively monitor network traffic to obtain sensitive information. In early hub-based Ethernet networks or today's Wi-Fi environments, data packets are sent in a broadcast format, making eavesdropping relatively easy. In modern switched networks, attackers can use  MAC overflow attacks to flood the switch with a large number  of packets with   forged source  addresses, exhausting its  address table capacity and forcing the switch into "broadcast mode," allowing them to monitor traffic across the entire network.MACMAC

Modification

Attackers actively modify, insert, or delete data during transmission. For example, they can change the destination address of a packet or tamper with  DNS responses to redirect users to malicious websites. To avoid detection, attackers often recalculate and modify the packet's checksum. The primary defenses against tampering are  secure hashes  and  message authentication codes (MACs)  .

Replay

An attacker intercepts legitimate communication data and resends it at a later time to deceive the system. For example, they might intercept a transfer request and resend it. An effective defense against replay attacks is to ensure  idempotence of protocol operations  , meaning that repeated execution of the same operation does not produce additional side effects, or to incorporate timestamps or one-time random numbers (nonces) into the protocol.

Man-in-the-Middle (MITM)

This is one of the most classic and dangerous attacks. The attacker inserts himself between two communicating parties and impersonates the other party, thus being able to eavesdrop, tamper with, or even completely control the communication between the two parties without the knowledge of the two parties.

ARP spoofing  is a common method implemented in local area networks  MITM . The attacker forges  ARP responses, causing the user's traffic to be mistakenly sent to the attacker's machine, which then forwards it to the real gateway.

# 正常通信 (Normal Communication)
# User A 的流量直接发往 Gateway
[ User A ] ----> [ Gateway ] ----> [ Internet ]

# ARP 欺骗后的通信 (Communication after ARP Spoofing)
# User A 的流量先被 Attacker 截获，再由 Attacker 转发
[ User A ] ----> [ Attacker ] ----> [ Gateway ] ----> [ Internet ]
1.
2.
3.
4.
5.
6.
7.

Denial of Service (DoS)

DoS Attacks and their distributed versions  DDoSaim to deplete a target's network bandwidth, computing resources, or connections, rendering it unable to provide services to legitimate users. DDoS Attacks typically consist of a single control point and a large number of controlled "botnets." Attack methods are diverse and cover all levels of network protocols:

Network layer

• Ping Flood :  Overwhelms the target  with a massive amount of  data packets.ICMP Echo Request
• Smurf attack  : A message forged as the victim  IP is  ICMP Echo Request sent to a network's broadcast address, causing all devices on the network to reply to the victim  IC-MP Echo Reply, creating a traffic amplification effect.
• IP Fragment Flooding  : Sending a large number  IP of fragments but deliberately not sending the last fragment, forcing the target server to continuously allocate memory to reassemble the data packets, eventually exhausting resources.

Transport layer

• SYN Flood  : Exploiting  TCP the flaws in the three-way handshake, the attacker sends a large number  IP of packets with  forged sources SYN . The server allocates resources for these half-open connections and waits  ACK, eventually exhausting the connection table.

Application Layer

• DNS Amplification Attack  : The attacker forges the victim   to send a short request  IP to a large number of open  resolvers, and  the server returns a very large response to the victim, thereby amplifying the attack traffic.DNSDNS
• SSL/TLS handshake attack  : SSL/TLS During the handshake process, the server needs to perform computationally intensive public key decryption operations. The attacker exhausts the server's  CPU resources by initiating a large number of handshake requests.

Hijacking

BGP hijacking  : BGP hijacking BGP is an internet routing protocol. The attacker's autonomous system (AS) can maliciously declare an  IP address block that doesn't belong to it to the world, thereby "hijacking" traffic destined for that  IP block and redirecting it to their own network. Pakistan Telecom's accidental hijacking of YouTube traffic in 2008 is a well-known example.

TCP Connection Hijacking  : An attacker  TCP injects malicious data between two communicating parties that have established a connection by predicting the sequence number, thereby taking over the  TCP connection.

Metadata Privacy

Even if the communication content is encrypted, the data packet  IP header information (such as source/destination address, packet size, and communication time) remains in plain text. This metadata can also expose a large amount of private information.

Forging a Strong Shield: A Core Cryptography Toolbox

Cryptography is the mathematical foundation of network security and provides us with a powerful weapon against the above threats.

Secure Hash Algorithm

A hash function converts an input (message) of arbitrary length into an output (hash value or digest) of fixed length. A secure hash function should have two key properties:

1. One-way  : It is computationally infeasible to deduce the original input from the hash value.
2. Collision-resistant  : It is computationally infeasible to find two different inputs such that they hash to the same value.

The main use of hashing is to verify  integrity  . SHA-256 and  SHA-3 are currently recommended algorithms, while  MD5 and  SHA-1 have been shown to have serious security flaws and should be avoided.

Message Authentication Code (MAC)

MAC Also known as  a keyed hash  , it combines a secret key  K with the message  M to generate an authentication tag. The receiver recalculates the tag using the same secret key and the received message and compares it with the received tag. If they match, it proves that the message  has not been tampered with during transmission (integrity)  and that it originated  from the sender holding the same secret key (authenticity)  . This is a  standard method HMAC based on hash functions  .MAC

An important practical principle is  to encrypt first and then authenticate (Encrypt-then-MAC)  , that is, to calculate the value of the encrypted ciphertext  MAC .

Symmetric Encryption

Symmetric encryption uses the same key for both encryption and decryption. Its advantage is that it is fast and suitable for encrypting large amounts of data.

One-Time Pad (OTP)  : The most theoretically secure encryption method. It uses a completely random key of the same length as the plaintext, XORed with the plaintext XOR. Its security is impeccable, but it presupposes that the key is truly random, used only once, and securely distributed. These stringent requirements make it virtually unusable in practice.  Key reuse is a fatal flaw  . If the same key is used to encrypt two different messages  m1 ,  m2an attacker can  c1 XOR c2 directly obtain  m1 XOR m2the key and decrypt the ciphertext.

Stream ciphers  : These emulate a one-time pad, using a seed key to generate a sufficiently long pseudo-random keystream, which is then XORed with the plaintext. Early Wi-Fi encryption protocols  WEP used stream ciphers, but they were quickly broken due to design flaws.

Block ciphers  divide plaintext into fixed-size blocks (e.g., 128 bits) and then encrypt each block.  AES (Advanced Encryption Standard) is currently the most popular and secure block cipher standard. To encrypt messages longer than a single block, different modes of operation  are required   .

• Electronic Code Book (ECB) mode  : This is the simplest, but also the least secure, mode. It encrypts each plaintext block independently. If there are repeated blocks in the plaintext, the encrypted ciphertext will also contain repeated blocks, revealing the original data pattern.  Never use ECB mode!
• Cipher Block Chaining (CBC) mode  : To address  ECB this issue, CBC the mode XORs the plaintext block with the previous ciphertext block before encrypting the current block. This results in different ciphertext blocks even for identical plaintext blocks, thus concealing the data pattern. CBC A random and unpredictable  Initialization Vector (IV) is required  as the "previous ciphertext block" for the first block.

Public-key Cryptography

Public key cryptography, also known as asymmetric encryption, uses a pair of keys: a  public key  and a  private key  . The public key can be distributed publicly, while the private key must be kept strictly confidential by its owner.

• Encrypted communication  : Anyone can encrypt information using the recipient's public key, but only the recipient holding the corresponding private key can decrypt it. This perfectly solves the key distribution problem in symmetric encryption.
• Digital Signature  : The sender can "sign" the hash value of a message using their private key. The receiver can then verify the signature using the sender's public key. If the signature is verified,  the integrity  and  authenticity of the message are confirmed  (i.e., the message was indeed sent by the owner of the private key and has not been tampered with).

RSA It is the most famous public-key algorithm. Compared to symmetric encryption, public-key encryption is computationally expensive. Therefore, in practice, a hybrid approach is often adopted:  using public-key encryption to securely negotiate a temporary symmetric key, which is then used to efficiently encrypt data  .

Key exchange and forward secrecy

The Diffie-Hellman  key exchange protocol allows two communicating parties to negotiate a shared secret known only to them over a completely open channel. Even an eavesdropper monitoring the entire exchange process cannot learn the secret.

A crucial concept is  forward secrecy  . It means that even if the server's long-term private key is compromised at some point in the future, an attacker cannot use it to decrypt previously intercepted communications. The key to achieving forward secrecy is to use a temporary, expiring key (for example  Ephemeral Diffie-Hellman) for each session, rather than directly using the server's long-term private key.

Temporary keys don't "transmit" the private key itself. Instead, both parties generate a temporary key pair and exchange only a temporary public key. Using the (Ephemeral) Diffie–Hellman mathematical operation, both parties locally calculate the same shared secret key. Even if an attacker later obtains the long-term private key, they cannot deduce the session key from the public key recorded in the handshake (assuming the discrete logarithm problem is unsolvable).

Key Differences — RSA Key Exchange vs. Ephemeral DH (DHE/ECDHE)

• In a traditional RSA key exchange (early TLS configurations), the client generates  pre-master and encrypts the server's  long-term public key  before sending it. If an attacker later obtains the server's long-term private key, they can decrypt the recorded handshake and thus recover  pre-master and decrypt the past session—  there is no forward secrecy  .
• In  Ephemeral Diffie–Hellman (DHE/ECDHE)  , the client and server each generate a one-time (ephemeral) DH private key and its corresponding public key, exchanging only  the public keys  . The final session key is a shared value (e.g., ) calculated locally from each party's private key and the other party's public key. The private keys never leave either host and are never sent in plaintext. Even if an attacker later obtains the server's long-term private key, they cannot deduce the ephemeral private key or shared key from the handshake log  . Therefore, past sessions remain confidential—  achieving forward secrecy  .

Mathematical/implementation intuition  : The two parties exchange and (public keys), the client calculates , and the server calculates , which are the same. To deduce or from or requires solving the discrete logarithm problem (which is considered infeasible).

But note two exceptions/limitations:

1. If the implementation or configuration is wrong (for example, the server also records or leaks the ephemeral private key, or uses non-ephemeral DH parameters), forward secrecy will be broken.
2. If there are algorithms/hardware (such as large-scale quantum computers) in the future that can efficiently solve the corresponding mathematical problems, then the handshakes recorded now may also be decrypted - this is why encryption algorithms and parameters need to be updated periodically.

TLS 1.3 uses ephemeral key exchange based on (elliptical) DH by default, which naturally prioritizes forward secrecy; TLS 1.2 only has forward secrecy when using ECDHE/DHE, and does not have it when using RSA key exchange.

The foundation of trust: certificates and public key infrastructure

Public key cryptography is great, but it leaves one key question unanswered: How can I be sure this public key really belongs to me  Amazonand wasn't forged by some man-in-the-middle attacker?

The answer is  Public Key Infrastructure (PKI)  and  Digital Certificate  .

• Certificate  : A digital document issued by an authority that  www.google.combinds an identity (such as a domain name) to a public key.
• Certificate Authority (CA)  : A trusted third party that verifies the identity of the applicant and signs the applicant's certificate with its own private key.
• Chain of Trust  : Your operating system and browser come pre-installed with a set of "root  CA" certificates. When you visit a website (such as  google.com), it presents its own certificate. This certificate may have  CAbeen issued by an "intermediary," which in turn  was issued CA by the root  CA . By verifying the signatures at each level, your browser ultimately confirms  google.com that the certificate is trustworthy, thus establishing a chain of trust.

To prevent  CA hacking or abuse of power,  the Certificate Transparency Log (CTL)  mechanism was proposed. It requires all  CA public records of every certificate issued, allowing anyone to monitor and promptly detect unauthorized certificates.

Practical Analysis: How TLS/HTTPS Protects Your Communications

TLS (Transport Layer  Security) is the core of the TLS protocol  HTTPS . It sits  TCP above the application layer and below the application layer,  HTTP providing confidentiality, integrity, and authenticity protection for other application layer protocols. The following is  TLS a simplified version of the 1.2 handshake protocol:

1. Client Hello  : The client sends the server  TLS the versions it supports, a list of cipher suites, and a random number  random_c.
2. Server Hello  : The server selects a cipher suite from the list and returns its own certificate and a random number  random_s.
3. Key exchange  : The client verifies the server certificate. Once verified, it generates a  pre-master secret  , encrypts it with the public key in the server certificate, and sends it to the server.
4. Generate session keys  : The client and server now have  random_c, , random_s and  pre-master secret. They use these three random sources to calculate the exact same  master secret through a pseudo-random function (PRF)  . The master secret is then used to derive all symmetric keys required for the session (encryption keys, MAC keys, etc.).
5. Finished  : Each party sends a  Finished message containing  MAC the values ​​of all previous handshake messages, encrypted with the newly generated session key. This verifies that the entire handshake process has not been tampered with.

After the handshake is complete, both parties can use the negotiated symmetric session key to encrypt and authenticate application data. Modern  TLS (such as  TLS 1.3) will also give priority to using a key exchange algorithm that supports forward secrecy (such as  ECDHE).

The following is  TLS the process of 1.3 handshake protocol:

1. Client Hello  (Client):

• Contains the set of supported TLS versions, the list of cipher suites, key_share(the client's ephemeral public key, such as an ECDHE public key), psk /  early_data(if attempting 0-RTT), and extensions such as ALPN.
• The client calculates and saves the transcript (handshake message hash) of the handshake record.

2. (Possibly)  HelloRetryRequest  (server): If the server requires the client to use a different curve or key exchange parameters, it will return a HelloRetryRequest, and the client will send an updated one  ClientHello(with the new one  key_share).
3. ServerHello  (server): selects the version and cipher suite and returns its own  key_share(server ephemeral public key). At this point, both parties can derive a shared secret key (the shared value generated by ECDHE) based on their own ephemeral private key and the other party's public key.
4. Derived handshake keys  : Both parties use a mechanism such as HKDF to derive a "handshake key" based on a shared value and an early secret (if PSK is present) to encrypt/authenticate subsequent handshake messages.
5. EncryptedExtensions, Certificate, CertificateVerify, Finished (Server → Client)  : The server sends its certificate (if necessary) over the encrypted handshake channel,  CertificateVerify signs the certificate contents, and then sends them  Finished. These messages are encrypted/authenticated with the handshake key, preventing middlemen from tampering with the latter half of the handshake.
6. Client Verifies and Responds  : The client verifies the certificate chain  CertificateVerify, calculates the transcript hash, verifies the server's  Finished, and then sends it (encrypted) Finished to the server.
7. Encrypted Application Data  : Both parties use the application key derived from the master secret to encrypt subsequent application data (HTTP request/response).
8. Session Resumption/NewSessionTicket (optional, sent by the server after the handshake)  : The server can send it after the handshake is completed  NewSessionTicket, and the client can use it + PSK for session resumption or 0-RTT data transmission later.

0-RTT (zero-Round-Trip-Time) is a TLS 1.3 feature that allows the client to send application data with the first network packet (ClientHello), without waiting for the server to complete a full handshake. In other words, the client can send data in the "zeroth round trip," significantly reducing latency (especially useful for first-packet requests).

The basic HTTPS process is this: the application (HTTP) is layered over TLS, which is layered over the transport layer (usually TCP). The typical HTTPS process is: establish TCP, perform a TLS handshake over that TCP, and then send HTTP over the encrypted channel. However, modern variants (such as QUIC/HTTP/3) integrate TLS more closely with the transport layer.

Traditional HTTPS (HTTP/1.1, common HTTP/2 implementations):

1. DNS resolution → 2. Establish  a TCP  connection with the server (for example, to port 443).
2. A TLS handshake is performed on that TCP connection   (negotiating the protocol version, cipher suite, completing the key exchange and establishing the encrypted channel).
3. After TLS is completed,  HTTP  requests/responses are transmitted over the channel in encrypted form (HTTP messages are encapsulated and protected by TLS).
4. During the TLS handshake,   HTTP/2, HTTP/1.1, etc. can be negotiated through ALPN (Application-Layer Protocol Negotiation) .

HTTP/3 (QUIC) exception

• QUIC is a new UDP-based transport protocol that integrates transport layer functionality and TLS security into a single protocol. This means that QUIC simultaneously completes transport layer establishment and TLS security negotiation during the handshake (the TLS 1.3 handshake is embedded in QUIC). Therefore, there's no strict layering of TCP, TLS, and HTTP: instead, the connection flow is UDP → QUIC (with TLS embedded) → HTTP/3. This reduces connection establishment latency and improves migration and reconnection performance.

Other supplements

• TLS Session Resumption/PSK  : To reduce latency, clients can use session resumption or pre-shared keys (PSK) to skip the full handshake, thus reducing the RTT. TLS 1.3 is more efficient in this regard (0-RTT has risks: early data needs to be treated with caution regarding replay and some security properties).
• TLS itself is not designed specifically for HTTP. It can protect a variety of application layer protocols (SMTP, IMAP, database protocols, etc.), but HTTPS is its most common application scenario.

The Way to Security: A Design Philosophy Beyond Algorithms

Some high-level security principles that transcend specific technologies are as follows.

• Don't roll your own crypto  : Cryptography is extremely subtle, and a small implementation error can bring down the entire system. Always prioritize using publicly available, well-reviewed, and widely accepted standard libraries and implementations.
• Maintain Crypto Agility  : Design your system so that you can easily switch and upgrade encryption algorithms. If an algorithm is found to be insecure, you can quickly migrate to a stronger alternative.
• Cultivate a security mindset  : Always examine your system designs from the perspective of an attacker. Follow  the principles of defense in depth  and  least privilege  , assuming that any component can be compromised and design countermeasures accordingly.
• Assume the network is insecure  : This is the golden rule of network security design. Never trust the underlying network. Build your security protocols around the assumption that an attacker can eavesdrop, tamper with, replay, or hijack all your network communications.