Study Guide
HTTPS: TCP, TLS and web communication
Follow a web request through DNS, TCP, TLS and local delivery, with certificate, key and socket explanations.
Lesson 3.12 Networking Fundamentals
Visiting a secure website brings together almost everything in this module: names and addresses, ports, routing and encryption. This lesson follows one request from the moment an address is typed to the moment the page appears, and works out what the padlock in the browser does and does not protect.
Stage: Think
One second, one page
Think it through
You type a website’s name into a browser and the page appears about a second later. List everything the laptop must find out or set up in that second before it can show the page.
- Hint 1: Computers find each other by number. Where does the number come from?
- Hint 2: How would you know the site is genuine?
Show what happens
At least four things: the server’s address, found from its name; a connection to it; a way to be sure it is the real site and to keep the conversation private; and finally the request for the page itself. The lesson follows them in that order.
Think it through
Show the answer
Answer: B. Finding the server’s address.
Finding the address. Each job needs the one before it: you cannot connect without an address, or protect a connection that does not exist yet.
Stage: Explain
Start with a website address
A pupil on a school laptop types https://www.example.com/ into a browser and presses Enter. About a second later the page appears. In that second, four things happen in a fixed order.
The whole journey, one job at a time. Each job needs the one before it: the browser cannot connect before it has an address, or protect a connection that does not yet exist.
DNS
Step 1 of 4: Find
Turn the name www.example.com into an IP address.
TCP
Step 2 of 4: Connect
Open a reliable connection to that address, on port 443.
TLS
Step 3 of 4: Secure
Check the server is the real one, and agree a secret key with it.
HTTP
Step 4 of 4: Ask and answer
Send the request for the page and receive it, both encrypted with that key.
Think it through
HTTPS is not a separate technology. It is HTTP, the rules for asking for and sending web pages, carried inside TLS, which protects it. Underneath, TCP delivers the data reliably and IP gets it to the right computer, as the earlier lessons described.
In this example the web server’s address is 198.51.100.20, an address reserved for examples, and the laptop’s is 192.168.1.10.
Stage: Predict
1. Find the server with DNS
Think it through
You know a friend’s name but not their phone number. How do you find the number? How might a laptop find the address for www.example.com?
- Hint 1: Where do you look up a number you do not know?
Show what happens
Look it up in a directory. The internet has one: give it a name, and it returns the address.
Computers find each other by IP address, and people remember names. DNS (the Domain Name System) is the internet’s phone book: give it a name, and it returns the number.
The laptop asks, “what is the address of www.example.com?”, and receives the answer 198.51.100.20. If it asked the same question a few minutes ago, it reuses the answer it kept.
- The laptop checks its own cache for a recent answer.
- If there is none, it asks its configured DNS resolver, often supplied by DHCP, commonly over UDP port 53.
- If the resolver has no cached answer, it works through the DNS hierarchy on the laptop’s behalf until it finds a server that holds the answer for that domain.
- The answer, such as an IPv4 address record, comes back to the laptop, and both the resolver and the laptop keep it for a time.
Because ordinary DNS queries are not encrypted, they can reveal which sites a device is looking up, even when the sites themselves use HTTPS.
Think it through
Show the answer
Answer: B. No: it says only where to connect.
No. DNS says where to connect; it does not prove who answers there.
DNS is a separate service, not part of HTTPS. It tells the browser where to connect. It does not prove that whatever answers at that address is the real website. Proving that is TLS’s job, in step 3.
The laptop also needs its own network settings and a way out of the school’s network, which DHCP and ARP provided earlier.
Stage: Predict
2. Establish TCP transport
The browser now opens a connection from the laptop to the server. In the notation of TCP, UDP, Ports and Sockets:
192.168.1.10:51542 → 198.51.100.20:443
Port 443 is the agreed port for HTTPS. Port 51542 is a temporary port the laptop chose for its own end. (On the way out, the school’s router swaps the laptop’s private address for a public one, as IP forwarding, default gateways and NAT/PAT explained.)
Think it through
Before two people talk on the telephone, one rings, the other answers, and the first confirms they can hear. Why might two computers do something similar before sending a web page?
- Hint 1: What would happen if one side started talking before the other was ready?
Show what happens
Each side needs to know that the other is there and ready before data flows. TCP does this with three messages.
TCP begins with its three-message handshake: SYN (synchronise), SYN-ACK and ACK (acknowledge).
A simplified exchange between the laptop and the web server, message by message. Arrows show which way each message travels, not a direct physical cable.
- Step 1: Laptop to Web server. SYNI would like to open a connection.
- Step 2: Web server to Laptop. SYN-ACKAgreed, and I am ready too.
- Step 3: Laptop to Web server. ACKConfirmed. The connection is open.
From here, TCP numbers the data it sends, has the other side confirm what arrived, and resends anything that was lost. The result is a connection that delivers everything, in order.
Think it through
Show the answer
Answer: C. Neither, yet.
Neither, yet. TCP makes the connection reliable, not private or authenticated.
What TCP does not do matters just as much: it does not encrypt anything, and it does not check who is at the other end. At this point the laptop has a reliable connection to something at 198.51.100.20.
Go deeper What the server was doing before the laptop called
A web server program asks its operating system for a socket on port 443 and waits, which is called listening. When a handshake arrives and the firewall allows it, the operating system completes it and hands the new connection to the program. If nothing is listening on a port, the connection is refused; a firewall may instead silently discard the attempt. Many clients can use port 443 at once, because each connection has a different combination of client address and client port.
Stage: Predict
3. Negotiate TLS security
The connection is reliable but open: anyone on the path could read it, and nothing has shown that the server is genuine. TLS (Transport Layer Security) fixes both, by doing three jobs.
Job 1: check that the server is who it claims to be. The server presents a certificate. Think of it as an identity card for the website, issued by a trusted organisation called a certificate authority. The browser checks that the card names www.example.com, is in date, and was issued by an authority the browser trusts. The server also has to prove that the card is its own, not a copy. Public Key Infrastructure and Digital Certificates explains how.
Think it through
Both sides need the same secret key, but anyone on the path can read what they send. What is wrong with simply sending the key?
- Hint 1: Who else can read messages on the path?
Show what happens
Anyone watching would read it and could then decrypt everything. The key has to be agreed without ever being sent, which sounds impossible.
Job 2: agree a secret key without ever sending it. The two sides each contribute something, exchange some values in the open, and both arrive at the same secret key. Someone watching every message still cannot work the key out. That sounds impossible; Transport Encryption, Key Agreement and Forward Secrecy shows how it is done.
Job 3: encrypt everything with that key. From now on, both sides scramble what they send using the shared key, called a session key because it lasts only for this conversation.
The TLS handshake grouped into four stages by purpose, between the laptop and the web server. It is a summary, not a list of every message.
- Step 1: Laptop to Web server. HelloHere are the kinds of protection I support, and my contribution towards a shared key.
- Step 2: Web server to Laptop. HelloI choose this kind of protection, and here is my contribution. Both sides can now work out the same key.
- Step 3: Web server to Laptop. Certificate and proofHere is my certificate, and proof that it is mine.
- Step 4: Laptop to Web server. Checked: confirmThe laptop checks first: the name matches, the certificate is in date and it trusts who issued it. Then it confirms. Everything after this is encrypted.
Check your understanding
Show the answer
Answer: C. Warn: it cannot confirm who it is talking to.
Warn. The certificate must name the site, be in date and come from a trusted authority; one failure means the browser cannot confirm who it is talking to.
If the browser’s checks fail, it shows a warning instead of the page. A warning means job 1 failed: the browser could not confirm who it is talking to. It is not a formality to click through.
Go deeper The TLS 1.3 message names and what this summary leaves out
In the current version, TLS 1.3, the four stages of the handshake diagram are these messages:
- ClientHello: the client’s supported options and its key share, which is its contribution to the key. The key share is ephemeral: made for this connection and thrown away afterwards.
- ServerHello: the server’s choice and its own key share. Both sides now derive the keys.
- Certificate, CertificateVerify and Finished: the server sends its certificate with the certificates that link it to a trusted authority (the certificate chain), proves that it holds the matching private key (CertificateVerify) and confirms the whole exchange (Finished). These messages are already encrypted.
- The client’s Finished, sent once its checks pass.
The certificate’s key is used to prove identity. It is not used to encrypt the web pages, and the server’s long-term private key is not the session key. This summary describes a new connection in which only the server is identified. It leaves out resuming an earlier session and asking the client for a certificate too. The TLS 1.3 specification has the detail.
Stage: Predict
4. Send the protected HTTP request
Only now does the browser ask for the page. Before TLS protects it, the request is a few lines of plain text:
GET / HTTP/1.1
Host: www.example.com
Accept: text/html
GET / means “send me the home page”. TLS encrypts those lines with the session key, and TCP carries the result. Someone watching the connection sees scrambled data: they cannot read the request or change it without being detected.
Think it through
Show the answer
Answer: B. Yes, before it is encrypted.
Yes: the request exists in plain text inside the browser before it is encrypted, and inside the server after it is decrypted.
The protection covers the journey, not the two ends. The server decrypts the request in order to read it, so a server that has been broken into, or a browser with malicious software in it, sees everything.
Stage: Predict
5. Receive and render the response
The server reads the request, finds the page and sends it back, encrypted with the same session key. The browser decrypts it and draws the page. The page usually refers to images and other files, which the browser requests over the same connection, without repeating steps 1 to 3.
The result: the pupil sees the page, about a second after pressing Enter.
Think it through
Someone is watching the school’s network during that second. Before looking at the table, which could they see: the name looked up, the server’s address, the page requested, what was typed into a form?
- Hint 1: Which parts must be readable for delivery to work?
Show what happens
The name looked up and the server’s address are visible; the page and anything typed are not. The table explains why.
Here is the same second from the point of view of someone watching the school’s network.
| What an observer could see | Visible? | Why |
|---|---|---|
That the laptop looked up www.example.com | Yes | Ordinary DNS lookups are not encrypted. |
That the laptop connected to 198.51.100.20 on port 443 | Yes | Addresses and ports must be readable for the data to be delivered. |
| When, and roughly how much data was exchanged | Yes | Timing and size cannot be hidden by encryption. |
| Which page was requested and what it contained | No | TLS encrypted the request and the response. |
| Anything typed into a form on the page | No | It travels inside the same encrypted connection. |
That table is the honest meaning of the padlock.
Stage: Explain
How does a protocol make this happen?
A protocol is a set of agreed rules. Software follows them: the browser writes the HTTP messages, a TLS component does the checking and encrypting, and the operating system runs TCP and IP. The network card sends and receives the result without needing to understand any of it.
| Basic element | Role in this example |
|---|---|
| Application | The browser creates the request and consumes the response |
| Protocols | HTTP, TLS, TCP, IP and link protocols coordinate different responsibilities |
| NIC | Sends and receives network data through the interface |
| Transmission media | Copper, fibre or radio carries physical signals |
Check your understanding
Show the answer
Answer: A. Its destination MAC.
The destination MAC address. The switch never looks at the TCP port.
Two different things here are called “port”. Suppose the laptop’s cable is plugged into switch port 5: a physical socket. TCP port 443 is a number in software. The switch chooses where to send a frame from the destination MAC address, and never looks at the TCP port.
For a server outside the school, the frame leaving the laptop is addressed to the gateway’s MAC address while the packet inside is addressed to the web server’s IP address. The forwarding walkthrough follows that distinction, and the OSI overview places each protocol in its layer.
Stage: Predict
What HTTPS does not hide
HTTPS protects the content of the conversation. It does not hide that the conversation took place. IP addresses, timing and the amount of data remain visible, and DNS lookups reveal names unless they are protected separately.
A pupil at a fictional school reads an advice page on a charity’s website over HTTPS.
- The lookup. The laptop asks DNS for the charity’s address. Unless DNS is protected separately, the school’s network can see the name that was looked up.
- The connection. The network sees the laptop connect to the charity’s server address on port 443, when, and roughly how much data passes.
- The content. It cannot see which page was read or anything typed into a form: TLS encrypted them.
The result: the network can tell which site was visited, but not what was read there.
Think it through
Show the answer
Answer: C. Yes: it proves the name, not honesty.
Yes. A certificate shows that the browser reached the site named in the address bar, not that the site is honest.
A valid certificate also says nothing about whether a website is honest. It shows that the browser reached the site named in the address bar. A criminal can obtain a perfectly valid certificate for a site they own.
Stage: Explain
HTTP/3 uses a different transport sequence
Everything so far in this lesson describes HTTPS over TCP, which is what the older versions of HTTP (HTTP/1.1 and HTTP/2) use. The newest version, HTTP/3, does not use TCP at all. It runs over a protocol called QUIC, which runs over UDP, usually on UDP port 443. QUIC builds in TLS 1.3 and its own reliable delivery, so there is no separate TCP three-way handshake and the page is still encrypted. See the HTTP/3 specification.
So the four-step order in this lesson is typical for a new connection over TCP, not a rule for every page load. A cached DNS answer skips step 1, a connection that is already open skips steps 1 to 3, and HTTP/3 replaces step 2.
Check your understanding
Show the answer
Answer: B. Finding, connecting and securing.
Steps 1 to 3: the address is known and the connection is already open and protected, so only the request and response remain.
Certificate warnings are worth taking seriously. A mismatched name or an untrusted certificate can mean a misconfigured site, but it can also mean someone is intercepting the connection. Report it rather than clicking through, especially on a work device.
Stage: Apply
Apply it in a new situation
These questions use the lesson in situations it has not shown. For the strongest test of your understanding, come back to them on another day and answer each one at the first attempt.
Apply it
Show the answer
Answer: A. That they used the bank, and when.
That they visited the bank, when, and roughly how much data was exchanged; not the balance, the pages or anything typed.
Apply it
Show the answer
Answer: C. Report it rather than click through.
Report it. The warning means the browser could not confirm the server’s identity: a misconfiguration, or someone intercepting the connection.
Apply it
Show the answer
Answer: A. Finding the address.
Finding the address: “not found” means the name could not be turned into an address, so nothing after it could start.
Stage: Check
Check your understanding
These questions come from the approved revision bank. Choose an answer and check it; the explanation and its sources follow.
Show answer
Answer: Compatible higher-layer protocols enable communication; HTTP/3 uses QUIC over UDP.
Different physical technologies can communicate through compatible higher layers. HTTP defines web messages and TLS secures them; HTTP/3 uses QUIC over UDP, while HTTP/1.1 and HTTP/2 commonly use TCP 443. UDP does not imply an absence of encryption.
Revision sources: Session 5: Networking Fundamentals — Part 1 (Classroom session record)
Show answer
Answer: HTTPS is HTTP secured with TLS; HTTP/2 commonly uses TCP port 443, so the connection starts with the TCP handshake. QUIC over UDP port 443 is used by HTTP/3.
HTTPS uses HTTP with TLS, HTTP/1.1 and HTTP/2 commonly use TCP port 443, and HTTP/3 uses QUIC over UDP port 443. A TCP connection starts with SYN, SYN-ACK and ACK. The colleague has described HTTP/3, not HTTP/2. TLS does not replace the transport protocol, and HTTPS is not carried on port 80.
Revision sources: Session 5: Networking Fundamentals — Part 1 (Classroom session record)
Show answer
Answer: DNS resolution, then TCP connection to port 443 (SYN, SYN-ACK, ACK), then TLS handshake, then encrypted HTTP request and response.
A simplified sequence for HTTPS over TCP is: resolve the server’s IP address, using DNS when necessary; establish a TCP connection, typically to port 443, with SYN, SYN-ACK and ACK; perform the TLS handshake, which authenticates the server and establishes keys; then exchange encrypted HTTP. TLS needs the TCP connection to exist first, and HTTP is only sent once TLS protection is in place. This is the typical order for a fresh connection: a cached DNS answer or a reused connection skips steps, and HTTP/3 does not use a TCP handshake at all.
Revision sources: Session 5: Networking Fundamentals — Part 1 (Classroom session record) · HTTPS: TCP, TLS and web communication (Supplementary Study Guide explanation)
Show answer
Answer: TLS protects the HTTP requests and responses in transit for confidentiality and integrity.; The connection authenticates the server for bank-login.example through successful certificate validation and the TLS handshake.
TLS provides encryption, integrity protection and authentication, and the TLS handshake authenticates the server. Authentication rests on successful certificate validation for the hostname, so it authenticates the server for bank-login.example; it does not show that the name belongs to a genuine bank. TLS also has limits: it does not make an operator trustworthy, does not hide IP addresses, timing or traffic volume, and cannot protect data from a compromised browser, which sees the decrypted content.
Revision sources: Session 5: Networking Fundamentals — Part 1 (Classroom session record) · HTTPS: TCP, TLS and web communication (Supplementary Study Guide explanation)
Show answer
Answer: HTTP/3 uses QUIC over UDP, so there is no TCP three-way handshake; the guide should describe the TCP sequence as typical for a new HTTP/1.1 or HTTP/2 connection.
Modern HTTP/3 uses QUIC over UDP rather than TCP, so a TCP three-way handshake cannot be universal to HTTPS. QUIC integrates TLS 1.3 security, so HTTP/3 traffic is still protected, and even over TCP a browser may reuse an existing connection, so “every page load” overstates the rule. The TCP sequence is typical for a new HTTP/1.1 or HTTP/2 connection.
Revision sources: Session 5: Networking Fundamentals — Part 1 (Classroom session record) · HTTPS: TCP, TLS and web communication (Supplementary Study Guide explanation)
Study and revision
Return to TCP, UDP, Ports and Sockets or the Networking & Protocols revision topic. Its questions cover foundational ports, compatible protocol stacks, TCP handshake order, the transports used by HTTP/2 and HTTP/3, the typical order of a new HTTPS connection and what TLS does and does not protect; a flashcard recalls the limits of TLS. Items that use this lesson’s supplementary explanation say so in their explanations. They are learning-only.
Stage: Consolidate
What to remember
- A new HTTPS page load does four jobs in order: find the address (DNS), connect (TCP), secure (TLS), then ask and answer (HTTP).
- DNS says where to connect; it proves nothing about who answers.
- TCP makes the connection reliable, but neither private nor authenticated.
- TLS checks the server’s certificate, agrees a session key without sending it, and encrypts the conversation.
- HTTPS hides content, not the fact of the conversation; a padlock does not mean a site is honest.
Key terms
- DNS (Domain Name System)
The system that translates domain names into IP addresses. It commonly uses port 53 over UDP and TCP.
- TLS (Transport Layer Security)
A protocol that protects data in transit with encryption for confidentiality and with integrity protection, and authenticates the server when certificate validation succeeds. HTTPS uses it to secure web traffic.
- HTTPS (Hypertext Transfer Protocol Secure)
HTTP protected by TLS. HTTP/1.1 and HTTP/2 commonly use TCP port 443, while HTTP/3 uses QUIC over UDP port 443.
Common misunderstandings
The padlock means the connection is protected and the certificate matched the name. It says nothing about whether the site or its owner is trustworthy.
Content is protected, but IP addresses, timing, traffic volume and ordinary DNS lookups can still be observed.
DNS is a separate service that finds the address. HTTPS starts only once the browser knows where to connect.
Lesson sources and acknowledgements
Sources and scope
This lesson develops the additional educational explanations from my Session 5 ChatGPT note-taking discussion, alongside the approved Learning Log. The scenario is illustrative, not a tutor quotation, packet capture or completed lab; 198.51.100.20 is a documentation address and says nothing about the real records for example.com. The log records the taught material and technical corrections; this page explains how the pieces work together.
- Taught in Session 5 (see the Session 5 Learning Log): HTTPS as HTTP secured with TLS, the simplified connection sequence, DNS resolution, TCP port 443, the TCP three-way handshake, TLS providing encryption, integrity protection and authentication, and HTTP/3 using QUIC over UDP.
- Supplementary explanation: the four-jobs overview, the DNS resolution steps, the three jobs of TLS and the identity-card comparison, the certificate-validation and key-exchange detail in the “Go deeper” notes, the observer’s table, what HTTPS does not hide, the caveats about cached, reused and HTTP/3 connections, the misunderstandings and the practical note. The diagrams are original.
- Where the full explanation is: certificates, certificate authorities and key agreement are taught from the beginning in Module 6. This lesson describes what they achieve and leaves how they work to lessons 6.5 and 6.9.
Guided version (published 1 November 2026, awaiting the site owner’s editorial review): the one-second opening questions, every question asked in the lesson with its feedback and hints, the application questions and the closing summary are supplementary explanation written for the Study Guide. The settings are fictional. The questions in the lesson’s steps are not revision-bank items; those in “Check your understanding” are, unchanged.
A secret value that controls what a cipher does. The same algorithm with a different key gives a different result.
An application-layer protocol that automatically provides IP configuration, such as an address, subnet mask, default gateway and DNS server information.
A document, signed by a certificate authority, that binds a public key to the identity of its subject. The standard format is X.509.
The system that translates domain names into IP addresses. It commonly uses port 53 over UDP and TCP.
Transforming data with a cipher and a key so that it cannot be read without the right key. Decryption reverses it.
The unit of data at the Data Link layer, such as an Ethernet frame. It is addressed with MAC addresses for delivery across one local link.
The set of rules a web browser and a website use to ask for and send pages. A browser sends a request; the website sends a response.
HTTP protected by TLS. HTTP/1.1 and HTTP/2 commonly use TCP port 443, while HTTP/3 uses QUIC over UDP port 443.
A logical network-layer address identifying an interface for delivery across networks. IPv4 addresses are 32 bits; IPv6 addresses are 128 bits.
A link-layer address used for local frame delivery, conventionally 48 bits written in hexadecimal. It may be randomised or spoofed, so it is not proof of identity.
Hardware that connects a device to a network medium and provides Physical and Data Link layer functions.
The software that runs a computer and lets other programs use it. Windows, macOS, Linux, Android and iOS are operating systems.
The unit of data at the Network layer, such as an IP packet. It carries source and destination IP addresses between networks.
An agreed set of rules for how data is formatted, transmitted and interpreted so that devices can communicate.
A device that forwards traffic between networks, for example between a private local network and the internet.
A symmetric key used to protect one connection or one exchange of data, and then discarded.
A device that connects devices within a local network and forwards Ethernet frames using the MAC addresses it has learned.
A connection-oriented transport protocol that starts connections with a SYN, SYN-ACK, ACK handshake and provides reliable, ordered delivery.
A protocol that protects data in transit with encryption for confidentiality and with integrity protection, and authenticates the server when certificate validation succeeds. HTTPS uses it to secure web traffic.
A connectionless transport protocol that sends datagrams without first establishing a connection or guaranteeing delivery.
Your progress on this lesson
Saved in this browser only. It is not sent anywhere, does not follow you to another device, and is lost if you clear this site’s data.
This browser is not allowing the site to save progress, so it will be forgotten when you leave the page.