OpenCyber Academy
Technical · Chapter 2 · English
Course code: OCA-054Chapter 02: OCA-054-C002

Chapter 2 — Networks and protocols

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 02 published. Map, example, EX005.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 A request step by step"]
  N2["2.2 What each layer protects"]
  N3["2.3 Symptoms by layer"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX005"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 A request step by step"]
  N2["2.2 What each layer protects"]
  N3["2.3 Symptoms by layer"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX005"]

[Learning outcomes]
    |
    v
[2.1 A request step by step]
    |
    v
[2.2 What each layer protects]
    |
    v
[2.3 Symptoms by layer]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX005]

Learning outcomes

You will (1) trace a tracking-portal request through DNS, TCP and TLS; (2) explain what each layer protects; (3) match common symptoms to the layer that failed.

2.1 A request step by step

When a customer opens track.lumen.example, the browser first asks DNS for an address, then opens a TCP connection to port 443, then runs a TLS handshake, and only then sends the HTTP request carrying the parcel number. Tomás draws these steps as four boxes. He notes that plain DNS is not encrypted or authenticated, so a forged answer could send the browser to the wrong host. TLS limits the damage: the impostor cannot present a valid certificate for the Lumen name, so the browser stops. That is why certificate validation must never be switched off, even during testing.

2.2 What each layer protects

TCP gives ordered delivery but no secrecy; anyone on the path can read and change plain TCP data. TLS 1.3, specified in RFC 8446, adds confidentiality through authenticated encryption, integrity of every record and authentication of the server through its certificate. It does not hide the server's IP address, and in most deployments the requested name is still visible in the handshake. Tomás writes this down because a manager once claimed that TLS makes traffic invisible. Being precise about what a layer does and does not protect is the first step to diagnosing a failure correctly.

2.3 Symptoms by layer

Priya gives Tomás a list of help-desk tickets. A name that does not resolve is a DNS problem. A connection that times out points to routing or a firewall at the TCP layer. A browser warning about an untrusted or expired certificate is a TLS problem. A page that loads but shows an error message is an application problem. Sorting tickets by layer saves time, because each layer has different tools: dig or nslookup for DNS, a port test for TCP, a handshake test for TLS and the server logs for the application.

Worked example

Tomás sorts eight synthetic tickets into DNS, TCP, TLS and application, and attaches the matching first diagnostic tool to each.

Synthetic case. Ticket texts and hostnames are invented; RFC 8446 is real.

Errors and limits

Real faults can span layers, such as a firewall that breaks TLS by intercepting it. Layer sorting is a starting hypothesis, not a verdict.

Exercises

Synthesis

Diagnosing network problems starts with knowing which layer protects what and which tool inspects each layer.

Continue studying — chapter 02 of 18

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →

Worked answers

EX005. DNS resolution, TCP connection to 443, the TLS handshake, then the HTTP request with the parcel number.

EX006. Because the impostor host cannot show a trusted certificate for track.lumen.example, so the browser aborts the handshake.

EX007. The server's IP address and, in most deployments, the server name in the handshake; sizes and timing also leak.

EX008. It is a TLS-layer fault; run a handshake test such as openssl s_client and read the certificate's notAfter date.