Chapter 11 — Networks and protocols | Engineering Application and software supply chain security

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

Chapter 11 — Networks and protocols

Lesson map

Lesson 11 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes"]
  N1["11.1 Web requests"]
  N2["11.2 TLS"]
  N3["11.3 Package downloads"]
  N4["11.4 Restricting egress"]
  N5["11.5 Internal mirror"]
  N6["11.6 Monitoring"]
  N7["Certificate checks in code"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["11.1 Web requests"]
  N2["11.2 TLS"]
  N3["11.3 Package downloads"]
  N4["11.4 Restricting egress"]
  N5["11.5 Internal mirror"]
  N6["11.6 Monitoring"]
  N7["Certificate checks in code"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]

[Learning outcomes]
    |
    v
[11.1 Web requests]
    |
    v
[11.2 TLS]
    |
    v
[11.3 Package downloads]
    |
    v
[11.4 Restricting egress]
    |
    v
[11.5 Internal mirror]
    |
    v
[11.6 Monitoring]
    |
    v
[Certificate checks in code]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes

You will (1) explain how web requests travel and are protected; (2) describe TLS at a conceptual level; (3) identify where package downloads can be intercepted or altered; (4) apply network controls to the build pipeline.

11.1 Web requests

A rider's phone sends an HTTPS request to ticket-web. DNS finds the server address, TCP carries data, TLS encrypts and authenticates the connection, and HTTP carries the request and response. A weakness at any layer can expose data.

If DNS answers are forged, the phone may connect to the wrong server; TLS certificate checks catch that. If TLS is misconfigured, data may be readable in transit. If the application layer has a flaw, encryption does not help, because the attack arrives inside a valid connection. Each layer protects against different failures, so none can be skipped on the assumption that another covers it.

11.2 TLS

TLS lets the phone check that it is talking to Coastline's real server, using a certificate signed by a trusted authority, and then encrypts traffic. OWASP Top 10:2021 A02 Cryptographic Failures includes sending sensitive data without proper encryption.

The certificate binds the name of Coastline's server to a public key, and the trusted authority's signature vouches for that binding. If an attacker presents a certificate for another name, or one signed by an unknown party, the phone refuses. Encryption without authentication would be pointless, since the phone might be encrypting traffic to the attacker. Kwame checks that ticket-web redirects plain HTTP requests to HTTPS.

11.3 Package downloads

Build servers download dependencies over the network. If downloads used plain HTTP, or if certificate checks were disabled, an attacker on the network could substitute a different package. Coastline's builds use HTTPS only, with checks enabled, and verify each package against a lockfile hash.

The lockfile hash is a second, independent check. Even if a mirror or registry were compromised and served a different file over a valid HTTPS connection, the hash would not match and the build would stop. TLS protects the transfer; the hash protects the content. Together they mean a substituted package needs both a broken connection and a matching hash, which is far harder.

11.4 Restricting egress

Build machines are allowed to reach only the package registry mirror and source host. Unexpected outbound connections during a build are blocked and logged, which limits what a malicious install script could reach.

Malicious packages often send stolen environment variables to an attacker's server or fetch a second stage during installation. An egress allowlist blocks both unless the attacker's host happens to be on the list. The log of blocked attempts is itself useful: a new package that tries to reach an unknown host is investigated before anyone decides whether to allow it.

11.5 Internal mirror

Coastline uses an internal mirror of approved packages. It reduces dependence on the public registry's availability and gives one place to apply checks.

When a package is approved, its exact version is copied into the mirror; builds fetch only from there. If the public registry removes or replaces a version, Coastline's builds are unaffected. Checks such as malware scanning and licence review run once at the point of entry. The mirror must itself be protected and patched, since it becomes a single trusted source for every build.

11.6 Monitoring

Network logs from the build environment are kept, so the team can check what a build contacted.

Logs record the destination, time and build identifier for each connection, so an analyst can match unusual traffic to a specific job and commit. They are kept for long enough to cover the time it usually takes for a malicious package to be discovered and reported publicly. A weekly report highlights any new destination, which a reviewer either explains or investigates. Unexplained destinations are treated as possible incidents until shown otherwise.

Certificate checks in code

Kwame searches the codebase for any setting that turns off certificate verification and finds one in an old test script. It is removed, and a CI check now fails any change that disables verification.

Worked example

A build fails because a new dependency's install step tries to download extra files from an unlisted host. The egress block stops it. Investigation shows the package downloads optional fonts; the team chooses a different package that does not need network access at install time.

Synthetic case. Network setup and events are synthetic.

Errors and limits

Network controls cannot stop a malicious package that only uses allowed hosts.

Exercises

EX031 — TLS role. What two things does TLS provide? Rubric: 3 = authentication of server and encryption; 2 = one; 1 = vague; 0 = none.
EX032 — Download protection. How are package downloads protected? Rubric: 3 = HTTPS with checks; lockfile hash; 2 = partial; 1 = vague; 0 = none.
EX033 — Egress block. What happened when a package tried to reach an unlisted host? Rubric: 3 = blocked; chose different package; 2 = partial; 1 = vague; 0 = none.

Synthesis

Protect the path packages travel and limit where builds can connect.

Continue studying — chapter 11 of 50

← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →