How HTTPS Uses TLS to Secure Data in Transit

Hello again. In the previous lesson, you learned that HTTP gives client-server communication a shared message format: methods, paths, headers, bodies, and status codes. But ordinary HTTP does not protect those messages while they cross networks you do not control. A Wi-Fi operator, network provider, or active attacker positioned on the path could potentially inspect or alter plain HTTP traffic.

This lesson explains how HTTPS, which is HTTP carried inside TLS (Transport Layer Security), establishes a protected channel before HTTP messages flow. By the end, you should be able to explain the TLS handshake at the level expected in an entry-level system-design interview, including certificates, session keys, and the security properties HTTPS does—and does not—provide.

---

The problem HTTPS solves

Suppose a browser sends this ordinary HTTP request:

POST /v1/orders HTTP/1.1
Host: shop.example.com
Authorization: Bearer <access-token>
Content-Type: application/json

{"productId":"p42","quantity":1}

Without TLS, the HTTP message is just readable application data inside network packets. Someone able to capture traffic on the route could read the bearer token and order details. An active attacker might even change the request before it reaches the server—for example, changing the destination account in a payment request.

HTTPS protects against this kind of on-path or “man-in-the-middle” attack. It provides three related properties:

Property	What TLS provides	Example
Confidentiality	Data is encrypted in transit.	A network observer cannot read an authorization header or JSON body.
Integrity	Undetected changes to protected data are rejected.	An attacker cannot silently change quantity: 1 to quantity: 100.
Authentication	The client can verify that it is communicating with the intended server.	A browser can distinguish bank.example from an attacker impersonating it.

Read the opening and handshake portions of MDN’s Transport Layer Security (TLS) guide. It provides a concise definition of these three security goals before connecting them to the handshake.

A compact definition worth retaining is:

HTTPS is HTTP over TLS. TLS authenticates the server and establishes protected session keys; HTTP requests and responses then travel through that protected connection.

HTTPS does not make the server inherently trustworthy, validate application inputs, prevent an authenticated user from misusing an API, or encrypt data in the server’s database. It specifically protects data in transit between the TLS endpoints.

---

TLS comes before HTTP

For the usual HTTPS connection over TCP, the broad order is:

1. The client resolves the hostname and establishes a TCP connection, conventionally to port $443$.
2. Client and server perform a TLS handshake.
3. Only after TLS has established protection does the client send its HTTP request.
4. The server returns its HTTP response through the same protected connection.

The TCP connection is necessary for traditional HTTPS, but it does not provide confidentiality, integrity, or server identity. TCP’s handshake establishes a reliable byte stream; the TLS handshake establishes the security context that protects the bytes on that stream.

A browser loading:

https://shop.example.com/products/42

therefore does not first send a visible GET /products/42 request. It first performs TLS negotiation. Once that succeeds, the request and its response are encrypted.

The following visual overview shows this separation between transport setup, TLS setup, and protected application data. It uses a simplified, older RSA-style explanation for the key-exchange portion; we will distinguish that teaching model from modern TLS shortly.

---

Step 1: the client and server negotiate

The handshake begins when the client sends a Client Hello. At a high level, it says:

• which TLS versions the client supports,
• which cryptographic algorithms it supports,
• information needed to establish fresh shared keys,
• the hostname the client intends to reach, in typical browser connections.

The server responds with a Server Hello, selecting mutually supported secure parameters. Modern deployments should use TLS 1.3; TLS 1.2 remains common, while TLS 1.0 and 1.1 are obsolete and should not be enabled.

You do not need to memorize cipher-suite names for a system-design interview. What matters is the reason for negotiation:

Both sides must select compatible, secure algorithms before they can derive keys and exchange protected HTTP traffic.

A TLS handshake has a performance cost because it requires communication before the first HTTP response can be returned. This is one reason that browsers and services reuse existing secure connections when practical. The important design conclusion is not “avoid TLS”; it is “use HTTPS everywhere and manage connection setup efficiently.”

---

Step 2: the server presents a certificate

The server needs to prove that it is truly the server for shop.example.com. Merely sending a public key would not be enough.

Imagine an attacker intercepts the connection and sends their own public key while claiming to be shop.example.com. If the browser accepted any received public key, it could establish encryption with the attacker instead of the real site. The traffic would be encrypted—but encrypted to the wrong party.

A digital certificate addresses this identity problem. At a useful high level, a certificate contains:

• the server’s public key,
• one or more domain names it is valid for,
• validity dates,
• a digital signature from a trusted Certificate Authority, or CA.

A CA is an organization trusted by browser and operating-system vendors to issue certificates after validating control of a domain. Browsers ship with a set of trusted root CA certificates. The server commonly sends not only its own certificate but also intermediate certificates that form a chain of trust leading back to one of those trusted roots.

Before accepting the server’s identity, the browser checks at least that:

1. The certificate’s domain name matches the hostname the user requested.
2. The certificate is within its validity period.
3. The certificate chain is cryptographically valid and leads to a trusted root.
4. The server demonstrates that it possesses the private key associated with the certified public key.

The certificate’s public key is public by design. Its security comes from the fact that the certificate is signed and its identity claims are verified, while the matching private key remains secret to the server operator.

If these checks fail, a browser displays a certificate warning rather than silently proceeding. Bypassing such a warning on a public network defeats a central protection of HTTPS.

---

Step 3: both sides establish fresh session keys

TLS uses two different kinds of cryptography because they solve different problems.

Cryptographic role	Main purpose in TLS	Why it is useful
Public-key cryptography	Authenticate the server and help establish a shared secret during the handshake	A public key can be distributed openly; its matching private key remains controlled by the server.
Symmetric cryptography	Encrypt and verify the large volume of HTTP data after the handshake	It is fast enough for requests, responses, images, API payloads, and streams.

The desired outcome is a fresh set of session keys known only to the client and genuine server. These are temporary keys for this connection or session, rather than the server’s long-lived certificate private key.

Older educational diagrams often describe this as follows: the client creates a session secret, encrypts it with the server’s public key, and the server decrypts it with its private key. That describes a historical RSA key-exchange pattern and conveys a useful intuition: the public/private key pair helps establish a secret that an observer cannot read.

However, modern TLS 1.3 normally uses ephemeral Diffie-Hellman key agreement, not RSA key exchange. At interview level, describe it this way:

The client and server exchange temporary public key material and independently derive the same shared secret. The server uses its certificate private key to authenticate the handshake. They derive fresh symmetric traffic keys from the shared secret.

This design gives modern TLS an important property called forward secrecy. If a server’s long-term certificate private key were compromised later, previously recorded TLS 1.3 sessions should still not become readable merely because that private key is exposed. Each session used independently generated temporary key material.

The supplied diagram is useful for seeing the major phases. Its “Client Key Exchange” and encrypted session-key depiction are a simplified legacy model; treat those boxes as representing the broader goal: authenticated creation of a shared, temporary secret.

---

Step 4: the handshake confirms the protected channel

Near the end of the handshake, each side sends a protected confirmation—often called a Finished message. This confirms that both participants derived the expected secrets and saw the same handshake conversation.

This matters because encryption alone is not sufficient. TLS also uses authenticated encryption or related integrity mechanisms so that a recipient can detect whether protected data was changed, injected, or replayed in an invalid way. An attacker who flips bits in encrypted traffic does not produce a valid modified request; the recipient detects the authentication failure and rejects it.

After the handshake completes, client and server have security parameters and traffic keys for their connection. They can now exchange application data safely.

---

What becomes encrypted in HTTPS?

Return to the HTTP request from the prior lesson:

POST /v1/orders HTTP/1.1
Host: shop.example.com
Authorization: Bearer <access-token>
Content-Type: application/json

{"productId":"p42","quantity":1}

Once TLS is active, the HTTP method, path, headers, and body are protected from ordinary network observers. The same is true for the HTTP response:

HTTP/1.1 201 Created
Content-Type: application/json

{"orderId":"o987","status":"confirmed"}

In other words, HTTPS does not change HTTP’s meanings. POST still means what the API defines it to mean; 201 Created still communicates a successful creation. TLS wraps the HTTP exchange in encryption and integrity protection.

Some connection-level metadata necessarily remains observable to the network, such as:

• the destination IP address and port,
• traffic timing,
• approximate packet and transfer sizes,
• often the hostname, although newer extensions can reduce hostname exposure in some cases.

So HTTPS means “the HTTP content is protected in transit,” not “all facts about the connection are invisible.”

Also notice that browser authentication is not the same as TLS authentication. TLS usually authenticates the server to the browser. A user logging in with a password, cookie, token, or passkey is an application-level authentication process that occurs inside the established TLS channel.

---

HTTPS in a system architecture

In a small application, the application server might terminate TLS itself:

Browser -- HTTPS -- application server

At scale, TLS often terminates at the first trusted infrastructure component, such as a CDN, load balancer, reverse proxy, or API gateway. That component decrypts the incoming HTTPS request, then forwards it to backend services.

The critical question is: where does the trusted boundary end?

There are two broad internal-traffic choices:

• Trusted private network with plaintext HTTP internally: simpler, but any system able to observe that internal network can read the traffic.
• TLS between internal components as well: preserves encryption across more hops. Mutual TLS can additionally authenticate services to each other.

You will encounter reverse proxies, load balancers, API gateways, and service-to-service authentication later in the course. For now, make the core system-design observation:

HTTPS protects traffic only between its TLS endpoints. If TLS terminates at a load balancer, the browser-to-load-balancer segment is protected; what happens afterward depends on the internal network and the service’s configuration.

An interview-ready statement might be:

Clients connect to the public API through HTTPS. The load balancer terminates TLS using a certificate for the API domain, validates the encrypted client connection, and forwards requests to healthy application instances. For sensitive internal traffic, I would also encrypt service-to-service connections.

That is precise without becoming a cryptography implementation discussion.

---

Key takeaways

• HTTPS is HTTP over TLS. HTTP preserves its request-response semantics; TLS protects the connection carrying those messages.
• TLS provides confidentiality, integrity, and usually server authentication, protecting against network observers and active on-path attackers.
• A TLS handshake happens before HTTP application data is sent. Client and server negotiate compatible security parameters and establish fresh session keys.
• A server certificate binds a domain name to a public key. The browser validates its hostname, dates, signatures, and chain to a trusted CA.
• Public-key cryptography authenticates the handshake and helps establish secrets; fast symmetric encryption protects the actual HTTP traffic.
• Modern TLS 1.3 generally uses ephemeral key agreement, giving forward secrecy; the “client encrypts a session key with the server public key” model is a useful but historical simplification.
• TLS protects traffic between its endpoints. In a production architecture, explicitly identify where TLS terminates and whether internal hops are also encrypted.

Next, you will trace a full web request—from DNS resolution and network routing through an application server and database—so these protocol layers become one end-to-end system picture.