Channel protection is not a LAN boundary

Lesson map

Lesson 15. Map, example, EX061.

flowchart TD
  C["Card reader to provider"] --> E["Encrypted channel"]
  O["Order site"] --> H["HTTPS"]
  E --> L["Neither fact splits the shop LAN"]
  H --> L
  L --> D["DNS and the resolver stay unprinted"]

Two protected hops are described. The inside network is a third problem.

Logical drawing

card data     reader -> provider, encrypted, not the office PC
orders        email and the platform site, HTTPS
accounts      office computer and a cloud backup
resolver      not printed

Learning outcomes

After this chapter, you should be able to:

1. Keep the card path off the office computer.
2. Explain what TLS protects and what it does not separate.
3. Leave the resolver, and any DNSSEC claim, unprinted.

15.1 TLS protects a conversation between two endpoints. The shop LAN is a different boundary.

Chapter 3 states a data-flow fact: card payment data goes from the reader to the payment provider, encrypted, and does not touch the office computer. Online orders arrive by email and through the platform's website, which uses HTTPS. Accounts sit on the office computer and in a cloud backup. The three items marked for the most protection are that computer, the email account, and the order-platform login. Those statements already separate "encrypted in transit" from "safe because it is near the till."

RFC 8446 defines TLS 1.3 as protection for records between the peers that complete the handshake. NIST SP 800-52 Rev. 2 is guidance for choosing and configuring TLS implementations. Both documents are about that channel. They do not insert a forwarding barrier between a customer phone and a till. A guest who can still reach the office computer, because isolation is false in the before dictionary, is on a path TLS between the card reader and the provider does not close. The fix for that path is the isolation control, tested in the narrow way chapter 4 describes. It is not a claim that HTTPS on the order site covers the café Wi-Fi.

Name resolution sits in front of those channels and is even less observed. NIST SP 800-81-2 explains why the DNS is part of a secure design: a name has to become an address before a TLS session to that name can start. The bakery file does not print a resolver address, a filtering policy, or a DNSSEC deployment. Chapter 3's dependency list names the internet connection, the router, the payment service, the hosted platform, and email. It does not name a resolver. Adding one would look precise and would not be evidence. The internet-failure note stays as written: online orders stop, and card payments may be limited depending on the provider. "May" is the provider's behaviour, which Leo did not measure. A mobile-data suggestion for the card reader is a suggestion. It is not a printed backup circuit.

15.2 Worked example

Lesson table; scroll horizontally to read all columns →

Synthetic case. The cloud backup is named as a place accounts are kept. No vendor is added.

Errors and limits

A protected payment channel can be intact while the café Wi-Fi still shares a network with the tills.

Apply

• EX061 — Which boundary is TLS? Card data goes encrypted to the provider and not through the office computer. The order site uses HTTPS. Does either fact isolate the guest network, and what resolver do you print?
  Show marking criteria

  Rubric: 3 = neither fact is LAN isolation; the card path stays off the office computer; the three protected items stay the office computer, email, and the order login; no resolver or DNSSEC deployment is added;; 2 = TLS stays a channel and no resolver is invented;; 1 = the card path only;; 0 = none.