Application Layer Protocols
DNS, HTTP/1-2-3, TLS 1.3, DHCP, modern DNS security (DoH/DoT), and essential application protocols
Chapter 6: Application Layer Protocols
The Seventeen-Second Outage That Cost Millions
On October 4, 2021, Facebook, Instagram, and WhatsApp disappeared from the internet. For 5 hours and 52 minutes, 3.5 billion users couldn’t access their accounts. E-commerce businesses lost sales. Emergency services lost a communication channel. Facebook’s stock dropped 5%—a $60 billion market cap loss.
The root cause? A BGP misconfiguration withdrew Facebook’s routes (covered in Chapter 7). But what made recovery so difficult was DNS. Facebook’s DNS servers became unreachable, so even after BGP was fixed, DNS caches worldwide still had no valid records. Worse, Facebook’s internal tools also relied on DNS—engineers couldn’t access the systems needed to fix the problem.
This incident illustrates a crucial truth: Application layer protocols like DNS aren’t just conveniences—they’re critical infrastructure. When DNS fails, the modern internet collapses. Understanding these protocols deeply isn’t just academic knowledge; it’s essential for building and defending reliable systems.
This chapter explores DNS, HTTP (including HTTP/2 and HTTP/3), TLS, DHCP, and other protocols that make the internet usable.
Where Users Meet Networks
Think about what happens when you open your laptop, connect to WiFi, and browse to your favorite website. In that simple action, dozens of protocols work together seamlessly—and most users never think about any of them.
The layers we’ve explored so far—Physical, Data Link, Network, Transport—are invisible to most users. They move bits, frames, packets, and segments reliably from point A to point B. But users don’t think in those terms; they think about web pages, emails, file transfers, and domain names.
The Application layer is where networking becomes useful. It’s where protocols translate human intent into network operations:
- Type “google.com” → DNS translates that name into an IP address
- Click a link → HTTP requests the web page
- See the padlock icon → TLS encrypts the connection
- Connect to WiFi → DHCP gives your computer an IP address
Understanding these protocols is crucial for security. Application layer attacks—DNS poisoning, HTTP request smuggling, SSL stripping—are among the most common in the wild. Unlike attacks on lower layers that require network proximity, application layer attacks can often be launched from anywhere on the internet.
In this chapter, we’ll work through the major application protocols in the order you’d encounter them when accessing a website: first, you need an IP configuration (DHCP), then you need to translate a domain name to an IP (DNS), then you establish a secure connection (TLS), and finally you request content (HTTP). Let’s start with the protocol that enables the entire naming system of the internet.
DNS: The Internet’s Phone Book
Before your browser can load a single pixel of a webpage, it needs to answer a fundamental question: “Where is this server?” When you type www.google.com, your computer has no idea where to send packets. It needs to translate that human-friendly name into an IP address. This is DNS’s job, and it’s so fundamental that almost nothing works when DNS fails—as Facebook learned the hard way in their 2021 outage.
The Problem DNS Solves
IP addresses are efficient for computers but terrible for humans. No one wants to memorize 142.250.80.46 to visit Google. The Domain Name System (DNS) translates human-readable names into IP addresses.
DNS is a distributed, hierarchical database—one of the largest on Earth. It’s also a fundamental attack target. Controlling DNS means controlling where users actually go when they type a domain name.
DNS Hierarchy
DNS organizes names in a tree structure, read right to left:
DNS Hierarchy
DNS Hierarchy:
═══════════════════════════════════════════════════════════════════
. (Root)
│
┌────────────────────┼─────────────────────┐
│ │ │
.com .org .net
│ │ │
┌───────┼───────┐ │ │
│ │ │ │ │
google amazon example wikipedia cloudflare
│ │ │ │ │
www aws www www www
│ │ │ │ │
FQDN: www.example.com.
│ │ │ │
│ │ │ └── Root (often invisible)
│ │ └────── Top-Level Domain (TLD)
│ └────────────── Second-Level Domain
└────────────────── Subdomain (hostname)Domain components:
- Root (.): The top of the hierarchy (usually invisible)
- TLD (Top-Level Domain): .com, .org, .net, .uk, etc.
- Second-Level Domain: google, amazon, wikipedia
- Subdomain: www, mail, api
The Fully Qualified Domain Name (FQDN) includes all components: www.google.com. (note the trailing dot representing root).
DNS Resolution Process
When you request www.example.com, your computer doesn’t know how to find it. Here’s how DNS resolution works:
DNS Resolution (Recursive Query)
DNS Resolution (Recursive Query):
═══════════════════════════════════════════════════════════════════
Your Computer Recursive Resolver Root Server
│ (e.g., 8.8.8.8) │
│ │ │
│ 1. "What's the IP │ │
│ for www.example.com?" │
├───────────────────────►│ │
│ │ │
│ │ 2. "Who handles .com?"
│ ├─────────────────────►│
│ │ │
│ │ 3. "Try these .com │
│ │ nameservers" │
│ │◄─────────────────────┤
│ │
│ │ .com TLD Server
│ │ │
│ │ 4. "Who handles example.com?"
│ ├─────────────►│
│ │ │
│ │ 5. "Try ns1.example.com"
│ │◄─────────────┤
│ │
│ │ example.com Nameserver
│ │ │
│ │ 6. "What's www.example.com?"
│ ├─────────────►│
│ │ │
│ │ 7. "93.184.216.34"
│ │◄─────────────┤
│ │
│ 8. "93.184.216.34" │
│ (also cached for │
│ TTL duration) │
│◄───────────────────────┤Key terms:
- Stub Resolver: Your computer’s DNS client
- Recursive Resolver: Does the work of querying multiple servers (your ISP’s DNS or 8.8.8.8, 1.1.1.1)
- Authoritative Server: The definitive source for a domain’s records
- Caching: Resolvers cache responses (based on TTL) to reduce queries
DNS Record Types
DNS stores more than just IP addresses:
| Record | Purpose | Example |
|---|---|---|
| A | IPv4 address | example.com → 93.184.216.34 |
| AAAA | IPv6 address | example.com → 2606:2800:220:1:… |
| CNAME | Canonical name (alias) | www → example.com |
| MX | Mail exchanger | Priority 10: mail.example.com |
| NS | Nameserver | ns1.example.com |
| TXT | Text (SPF, DKIM, verification) | “v=spf1 include:_spf.google.com ~all” |
| SOA | Start of Authority | Zone metadata, serial number, refresh times |
| PTR | Reverse lookup (IP to name) | 34.216.184.93.in-addr.arpa → example.com |
| SRV | Service location | _sip._tcp.example.com |
| CAA | Certificate Authority Authorization | Which CAs can issue certs |
DNS Security Issues
DNS was designed for functionality, not security:
No Authentication: Traditional DNS has no way to verify responses are authentic. Attackers can inject false responses.
Cache Poisoning: Trick a resolver into caching a false record, misdirecting all its users.
DNS Cache Poisoning Attack
DNS Cache Poisoning Attack:
═══════════════════════════════════════════════════════════════════
Normal resolution:
Client ──► Resolver ──► "bank.com = 1.2.3.4" (legitimate)
Cache poisoning:
1. Attacker triggers query for bank.com
2. Attacker floods resolver with fake responses
"bank.com = 6.6.6.6" (attacker's server)
3. If fake response arrives before real one AND
matches Transaction ID (16-bit, guessable!)...
4. Resolver caches the fake record
5. ALL users of that resolver go to attacker's site!
Kaminsky Attack (2008): Exploited this at scale
Mitigation: Source port randomization, DNSSECDNS Amplification: Small queries can generate large responses; attackers use this for DDoS.
DNS Tunneling: Encoding data in DNS queries to bypass firewalls (exfiltration, C2).
Modern DNS Security: DoH and DoT
Traditional DNS queries are unencrypted—anyone on the network path can see what domains you’re looking up. Two protocols address this:
DNS over HTTPS (DoH):
- DNS queries sent as HTTPS requests to resolvers
- Uses port 443 (same as web traffic)
- Encrypted and authenticated
- Hard to block (looks like normal HTTPS)
- Major browsers support it (Firefox, Chrome)
DNS over TLS (DoT):
- DNS queries wrapped in TLS
- Uses dedicated port 853
- Encrypted and authenticated
- Easier to identify and policy-control than DoH
DNS Privacy Comparison
DNS Privacy Comparison:
═══════════════════════════════════════════════════════════════════
Traditional DNS (Port 53):
┌─────────────────────────────────────────────────────────────────┐
│ Query: www.secretsite.com │
│ Visible to: ISP, network admin, anyone on path │
└─────────────────────────────────────────────────────────────────┘
DNS over TLS (Port 853):
┌─────────────────────────────────────────────────────────────────┐
│ TLS-encrypted payload │
│ Visible: That you're using DoT (port 853) │
│ Hidden: The actual queries │
└─────────────────────────────────────────────────────────────────┘
DNS over HTTPS (Port 443):
┌─────────────────────────────────────────────────────────────────┐
│ HTTPS request to dns.google or cloudflare-dns.com │
│ Visible: That you're accessing a DoH provider │
│ Hidden: Indistinguishable from normal HTTPS at network level │
└─────────────────────────────────────────────────────────────────┘DNSSEC: Adds cryptographic signatures to DNS records, allowing verification of authenticity. Adoption is incomplete but growing.
# DNS lookup commands
dig example.com
dig +short example.com A
dig example.com MX
dig -x 93.184.216.34 # Reverse lookup
dig +dnssec example.com # Check DNSSEC
nslookup example.com
host example.com
# Check if domain has DNSSEC
dig example.com +dnssec +multi
# Test DoH
curl -H 'accept: application/dns-json' \
'https://cloudflare-dns.com/dns-query?name=example.com&type=A'Security Note: DNS attacks are covered in Part II, Chapter 5. Understanding both traditional DNS vulnerabilities and modern security mechanisms is essential.
HTTP: The Web’s Foundation
Now that we understand how DNS translates names to IP addresses, let’s explore what happens next. Once your browser knows the server’s IP address, it needs to actually request content. This is where HTTP comes in—the protocol that powers the World Wide Web.
Think of DNS as looking up a phone number in a directory. HTTP is the actual conversation that happens once you dial. And just like phone conversations have evolved from simple voice calls to video calls with screen sharing, HTTP has evolved dramatically from its simple beginnings.
How the Web Works
The HyperText Transfer Protocol (HTTP) is the foundation of web communication. Every time you load a webpage, your browser uses HTTP to request resources from servers.
HTTP is a request-response protocol: the client sends a request, the server sends a response. It’s stateless—each request is independent; the server doesn’t inherently remember previous requests (cookies and sessions add state).
HTTP Request Structure
HTTP Request Format
HTTP Request Format:
═══════════════════════════════════════════════════════════════════
GET /index.html HTTP/1.1 ← Request line (Method Path Version)
Host: www.example.com ← Required header
User-Agent: Mozilla/5.0 ... ← Client identification
Accept: text/html,application/... ← Acceptable response types
Accept-Language: en-US,en;q=0.9 ← Language preferences
Accept-Encoding: gzip, deflate ← Compression support
Connection: keep-alive ← Connection handling
Cookie: session=abc123 ← State (if any)
← Empty line (end of headers)
[Optional Body for POST/PUT] ← Request body
Components:
- Method: What action to perform (GET, POST, PUT, DELETE, etc.)
- Path: The resource being requested (/index.html)
- Version: HTTP/1.1, HTTP/2, HTTP/3
- Headers: Metadata about the request
- Body: Data sent with request (forms, JSON, etc.)HTTP Methods
| Method | Purpose | Idempotent | Safe | Request Body |
|---|---|---|---|---|
| GET | Retrieve resource | Yes | Yes | No |
| POST | Submit data, create resource | No | No | Yes |
| PUT | Update/replace resource | Yes | No | Yes |
| PATCH | Partial update | No | No | Yes |
| DELETE | Remove resource | Yes | No | Optional |
| HEAD | GET without body (headers only) | Yes | Yes | No |
| OPTIONS | Query supported methods (CORS) | Yes | Yes | No |
| TRACE | Echo request (debugging) | Yes | Yes | No |
| CONNECT | Establish tunnel (proxies) | No | No | No |
Idempotent: Multiple identical requests have same effect as single request Safe: Doesn’t modify server state
HTTP Response Structure
HTTP Response Format
HTTP Response Format:
═══════════════════════════════════════════════════════════════════
HTTP/1.1 200 OK ← Status line (Version Code Reason)
Date: Mon, 20 Jan 2025 12:00:00 GMT
Server: nginx/1.24.0
Content-Type: text/html; charset=UTF-8
Content-Length: 1234
Cache-Control: max-age=3600
Set-Cookie: session=xyz789; HttpOnly; Secure
Connection: keep-alive
← Empty line (end of headers)
<!DOCTYPE html> ← Response body
<html>
<head><title>Example</title></head>
<body>Hello, World!</body>
</html>HTTP Status Codes
| Range | Category | Common Codes |
|---|---|---|
| 1xx | Informational | 100 Continue, 101 Switching Protocols |
| 2xx | Success | 200 OK, 201 Created, 204 No Content |
| 3xx | Redirection | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 4xx | Client Error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found |
| 5xx | Server Error | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable |
Security-relevant codes:
- 401 Unauthorized: Authentication required
- 403 Forbidden: Authenticated but not permitted
- 404 Not Found: Resource doesn’t exist (or hidden deliberately)
- 429 Too Many Requests: Rate limiting in effect
HTTP/2: Multiplexed Connections
HTTP/1.1 had a fundamental limitation: one request at a time per connection. Browsers opened 6-8 connections per domain to parallelize, creating overhead.
HTTP/2 (2015) introduced:
- Multiplexing: Multiple requests/responses on single connection
- Header Compression: HPACK reduces redundant header data
- Server Push: Server can send resources before client requests them
- Binary Protocol: More efficient than text-based HTTP/1.1
HTTP/1.1 vs HTTP/2
HTTP/1.1 vs HTTP/2:
═══════════════════════════════════════════════════════════════════
HTTP/1.1 (Sequential per connection):
Connection 1: Request 1 ──► Response 1 ──► Request 2 ──► Response 2
Connection 2: Request 3 ──► Response 3 ──► Request 4 ──► Response 4
Connection 3: Request 5 ──► Response 5 ...
HTTP/2 (Multiplexed single connection):
Connection: ┌ Request 1 ──────────────► Response 1 ┐
│ Request 2 ────────► Response 2 │
│ Request 3 ──► Response 3 │ All interleaved
│ Request 4 ────────────► Response 4 │ on ONE connection
└ Request 5 ────► Response 5 ──────────┘HTTP/3: QUIC-Based Web
HTTP/3 (standardized 2022) uses QUIC instead of TCP, eliminating head-of-line blocking:
HTTP/2 over TCP vs HTTP/3 over QUIC
HTTP/2 over TCP vs HTTP/3 over QUIC:
═══════════════════════════════════════════════════════════════════
HTTP/2 + TCP (Head-of-line blocking):
Stream 1: ████░░░░░░ ← Packet lost, waiting for retransmit
Stream 2: ████░░░░░░ ← BLOCKED (TCP sees one byte stream)
Stream 3: ████░░░░░░ ← BLOCKED (even though data arrived)
HTTP/3 + QUIC (Independent streams):
Stream 1: ████░░░░░░ ← Packet lost, waiting for retransmit
Stream 2: █████████ ← Continues normally!
Stream 3: ██████████ ← Continues normally!HTTP/3 benefits:
- 0-RTT connection establishment (with session resumption)
- No head-of-line blocking between streams
- Better mobile performance (connection migration)
- Built-in encryption
PRO TIP
To see which HTTP version a site uses:
curl -sI https://www.google.com | grep -i 'http/' # Or in browser DevTools: Network tab → Protocol column
HTTP Security Concerns
Plaintext Transmission: HTTP sends everything in cleartext—anyone on the network path can read it. Use HTTPS instead.
Header Injection: If applications incorporate user input into headers without validation, attackers can inject additional headers.
Request Smuggling: Exploiting differences in how frontend/backend servers parse HTTP to smuggle malicious requests.
Method Override Attacks: Some frameworks allow method override via headers (X-HTTP-Method-Override)—can bypass security controls.
Security Note: HTTP-specific attacks are covered in Part II, Chapter 5. Always use HTTPS for any sensitive communication.
HTTPS and TLS: Encrypted Communication
We’ve seen how HTTP enables web communication, but there’s a fundamental problem: HTTP sends everything in the clear. Anyone watching network traffic—your ISP, someone on the same WiFi network, or a malicious actor who’s positioned themselves in the path—can read every byte.
Imagine sending postcards through the mail instead of sealed envelopes. Anyone who handles your postcard can read it. That’s HTTP. What we need is a way to put our messages in a locked box that only the intended recipient can open. That’s what TLS provides, and when we use TLS with HTTP, we call it HTTPS.
The “S” in HTTPS stands for “Secure,” but understanding how that security works is crucial. TLS is arguably the most important security protocol on the internet—it protects not just web traffic, but also email, VPNs, and countless other applications.
The Need for Encryption
HTTP transmits everything in plaintext. On any network between you and the server—your WiFi, your ISP, internet exchanges—anyone can read your traffic. Usernames, passwords, credit cards, personal messages—all visible.
HTTPS (HTTP Secure) wraps HTTP in a TLS (Transport Layer Security) tunnel, providing:
- Confidentiality: Data is encrypted; eavesdroppers see only gibberish
- Integrity: Data cannot be modified without detection
- Authentication: Server proves its identity via certificate
TLS 1.3 Handshake
TLS 1.3 (2018) significantly improved over previous versions:
TLS 1.3 Handshake (1RTT)
TLS 1.3 Handshake (1-RTT):
═══════════════════════════════════════════════════════════════════
Client Server
│ │
│ ClientHello │
│ - Supported cipher suites │
│ - Key share (client's DH public key) │
│ - Supported versions │
├────────────────────────────────────────────────────►│
│ │
│ ServerHello │
│ - Chosen cipher suite │
│ - Key share (server's DH public key) │
│ EncryptedExtensions │
│ Certificate │
│ CertificateVerify │
│ Finished │
│◄────────────────────────────────────────────────────┤
│ │
│ ══════════ Keys derived, encryption starts ═══════ │
│ │
│ Finished (encrypted) │
├────────────────────────────────────────────────────►│
│ │
│ Application Data (encrypted) │
│◄═══════════════════════════════════════════════════►│
TLS 1.3 improvements over TLS 1.2:
- 1-RTT handshake (was 2-RTT)
- 0-RTT resumption available
- Removed insecure ciphers
- Forward secrecy mandatory
- Encrypted more of the handshakeCertificate Validation
When your browser receives a server certificate, it verifies:
- Chain of Trust: Certificate signed by a trusted CA (or chain to one)
- Domain Match: Certificate’s CN or SAN matches the domain
- Validity Period: Certificate hasn’t expired
- Revocation Status: Certificate hasn’t been revoked (OCSP, CRL)
Certificate Chain of Trust
Certificate Chain of Trust:
═══════════════════════════════════════════════════════════════════
┌─────────────────────────────────────────────────────────────┐
│ Root CA Certificate │
│ (Pre-installed in browsers/OS) │
│ "Trust me, I'm a Certificate Authority" │
└─────────────────────────┬───────────────────────────────────┘
│ Signs
▼
┌─────────────────────────────────────────────────────────────┐
│ Intermediate CA Certificate │
│ (Signed by Root CA above) │
│ "Root CA says I can sign certificates for domains" │
└─────────────────────────┬───────────────────────────────────┘
│ Signs
▼
┌─────────────────────────────────────────────────────────────┐
│ Server Certificate │
│ (Signed by Intermediate CA) │
│ "Intermediate CA says I'm really example.com" │
│ Contains: Public key, domain name, validity dates │
└─────────────────────────────────────────────────────────────┘
Browser verifies chain from server cert up to trusted rootTLS Security Considerations
Downgrade Attacks: Attackers try to force older, weaker TLS versions. TLS 1.3 includes protections, but servers supporting old versions remain vulnerable.
Certificate Issues: Stolen private keys, mis-issued certificates, or compromised CAs can undermine the entire system.
SSL Stripping: Attacker intercepts HTTP requests before they upgrade to HTTPS, keeping the victim on unencrypted HTTP.
HSTS (HTTP Strict Transport Security): Tells browsers to only use HTTPS for a domain. Mitigates SSL stripping.
HSTS Header:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Meaning:
- max-age: Remember to use HTTPS for 1 year
- includeSubDomains: Apply to all subdomains
- preload: Can be added to browser preload listsSecurity Note: TLS attacks are covered in Part II, Chapters 5 and 6. Understanding TLS is crucial for recognizing when encryption can be circumvented.
DHCP: Automatic Configuration
We’ve explored DNS, HTTP, and TLS—but all of these protocols assume your computer already has an IP address and knows where to send packets. How does your laptop get that IP address in the first place?
When you connect to a WiFi network, you don’t manually type in an IP address, subnet mask, gateway, and DNS servers. Something handles this automatically. That something is DHCP.
DHCP is one of those protocols that works so well that most people never think about it. But understanding how it works—and its security weaknesses—is essential. DHCP operates on trust, and that trust can be exploited in devastating ways.
The Problem DHCP Solves
For a computer to communicate on an IP network, it needs at minimum:
- An IP address
- A subnet mask
- A default gateway (router)
- DNS server addresses
Manually configuring these on every device is impractical. DHCP (Dynamic Host Configuration Protocol) automates this process.
DHCP Process (DORA)
DHCP uses a four-message exchange, often called DORA:
DHCP DORA Process
DHCP DORA Process:
═══════════════════════════════════════════════════════════════════
Client (no IP yet) DHCP Server
│ │
│ 1. DISCOVER (broadcast) │
│ "Any DHCP servers out there?" │
│ Src: 0.0.0.0 │
│ Dst: 255.255.255.255 (broadcast) │
├─────────────────────────────────────────────►│
│ │
│ 2. OFFER (unicast or broadcast) │
│ "Here's an IP you can use: 192.168.1.50" │
│ "Gateway: 192.168.1.1, DNS: 8.8.8.8" │
│◄─────────────────────────────────────────────┤
│ │
│ 3. REQUEST (broadcast) │
│ "I want 192.168.1.50 please" │
│ (Broadcast so other servers know) │
├─────────────────────────────────────────────►│
│ │
│ 4. ACKNOWLEDGE (unicast or broadcast) │
│ "OK, 192.168.1.50 is yours for 24 hours" │
│◄─────────────────────────────────────────────┤
│ │
│ Client configures interface │
│ 192.168.1.50 is now usable! │
Why broadcast? Client has no IP yet, can't receive unicast!DHCP Lease Renewal: Clients renew at 50% of lease time (T1) and rebind at 87.5% (T2).
DHCP Security Issues
DHCP has no authentication—any device can act as a DHCP server:
Rogue DHCP Server: Attacker sets up their own DHCP server, handing out their address as the default gateway. All victim traffic routes through the attacker—classic MITM.
DHCP Starvation: Attacker requests all available IP addresses with fake MAC addresses, exhausting the pool and causing denial of service.
Rogue DHCP Attack
Rogue DHCP Attack:
═══════════════════════════════════════════════════════════════════
Legitimate DHCP Server: 192.168.1.1
Rogue DHCP Server (attacker): 192.168.1.100
New client broadcasts DHCP Discover...
If attacker responds faster:
┌─────────────────────────────────────────────────────────────────┐
│ DHCP Offer from attacker: │
│ Your IP: 192.168.1.50 │
│ Gateway: 192.168.1.100 (attacker!) ← All traffic goes here! │
│ DNS: 10.66.66.66 (attacker's!) ← DNS hijacking too! │
└─────────────────────────────────────────────────────────────────┘
Victim unknowingly routes all traffic through attackerDefenses:
- DHCP Snooping on switches (only allow DHCP from trusted ports)
- 802.1X port authentication
- Monitor for rogue DHCP servers
Security Note: DHCP attacks are covered in Part II, Chapter 5.
Other Essential Protocols
DNS, HTTP, TLS, and DHCP are the foundational protocols for web access, but the application layer includes many more protocols that power different aspects of networked communication. Let’s briefly explore a few essential ones—each with its own security considerations.
Understanding these protocols helps you recognize what’s happening on a network and identify potential attack vectors. While we won’t go as deep as we did with DNS and HTTP, knowing what these protocols do and their security implications is important for any security professional.
SMTP: Email Transfer
SMTP (Simple Mail Transfer Protocol) transfers email between servers and from client to server.
| Port | Usage |
|---|---|
| 25 | Server-to-server (often blocked for end users) |
| 587 | Client submission (with authentication) |
| 465 | SMTPS (SMTP over TLS, legacy) |
SMTP Session Example
SMTP Session Example:
═══════════════════════════════════════════════════════════════════
S: 220 mail.example.com ESMTP ready
C: EHLO client.example.com
S: 250-mail.example.com Hello
S: 250-STARTTLS
S: 250 AUTH PLAIN LOGIN
C: STARTTLS
S: 220 Ready to start TLS
[TLS handshake occurs]
C: AUTH PLAIN base64(credentials)
S: 235 Authentication successful
C: MAIL FROM:<sender@example.com>
S: 250 OK
C: RCPT TO:<recipient@example.com>
S: 250 OK
C: DATA
S: 354 Start mail input
C: Subject: Test
C:
C: This is the message body.
C: .
S: 250 OK: queued
C: QUIT
S: 221 ByeSecurity concerns: Email spoofing (no authentication of sender), plaintext (use STARTTLS), spam. SPF, DKIM, and DMARC provide authentication.
SSH: Secure Remote Access
SSH (Secure Shell) provides encrypted remote shell access and secure file transfer (port 22). It replaced insecure protocols like Telnet and rsh.
# SSH connection
ssh user@hostname
# SSH with key-based authentication
ssh -i ~/.ssh/private_key user@hostname
# SCP (Secure Copy over SSH)
scp file.txt user@hostname:/path/
# SFTP (SSH File Transfer)
sftp user@hostname
# SSH tunneling (port forwarding)
ssh -L 8080:internal-server:80 user@bastion # Local forward
ssh -R 9000:localhost:22 user@remote # Remote forward
ssh -D 1080 user@proxy-server # SOCKS proxyFTP: File Transfer (Legacy)
FTP transfers files using two connections: control (port 21) and data (port 20 or dynamic).
Security concerns: Credentials sent in plaintext, complex firewall traversal, no encryption. Use SFTP (SSH-based) or FTPS (FTP over TLS) instead.
NTP: Time Synchronization
NTP (Network Time Protocol) synchronizes clocks across networks (port 123/UDP).
Why it matters for security:
- Certificates have validity periods
- Logs need accurate timestamps for forensics
- Kerberos authentication is time-sensitive
- TOTP (authenticator apps) depends on synchronized time
THINK ABOUT IT
Time seems like a simple concept, but in distributed systems, “what time is it?” is surprisingly hard to answer. If two servers’ clocks differ by a few seconds, log correlation becomes unreliable. If they differ by minutes, time-based authentication breaks. NTP is invisible infrastructure that makes security possible.
Putting It All Together: Practical Commands
Now that we understand these protocols conceptually, let’s see how to interact with them directly. These commands are essential tools for troubleshooting network issues and understanding what’s really happening when you access a website.
# DNS queries
dig example.com # Full query
dig +short example.com # Just the answer
dig @8.8.8.8 example.com # Query specific resolver
dig example.com MX # Mail servers
dig example.com TXT # TXT records (SPF, DKIM)
dig -x 93.184.216.34 # Reverse lookup
dig +trace example.com # Show full resolution path
nslookup example.com
host example.com
# HTTP testing
curl http://example.com # GET request
curl -I http://example.com # Headers only
curl -X POST -d "data=value" http://... # POST request
curl -v https://example.com # Verbose (shows TLS)
curl --http2 https://example.com # Force HTTP/2
curl --http3 https://example.com # Force HTTP/3 (if supported)
# View certificate
openssl s_client -connect example.com:443
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -text
# Check TLS configuration
nmap --script ssl-enum-ciphers -p 443 example.com
testssl.sh https://example.com
# DHCP lease info (Linux)
cat /var/lib/dhcp/dhclient.leases
dhclient -v # Verbose DHCP renewal
# View routing (default gateway from DHCP)
ip route # Linux
netstat -rn # macOS
route print # WindowsTRY IT YOURSELF
Trace a DNS lookup through the entire hierarchy:
dig +trace www.google.comYou’ll see queries to root servers, TLD servers, and finally authoritative servers.
Key Takeaways
-
DNS translates domain names to IP addresses using a hierarchical, distributed database—and is a critical security target
-
Modern DNS security (DoH, DoT, DNSSEC) addresses traditional DNS’s lack of encryption and authentication
-
HTTP has evolved from HTTP/1.1 (text-based, one request per connection) through HTTP/2 (multiplexed) to HTTP/3 (QUIC-based, eliminating head-of-line blocking)
-
TLS 1.3 provides encryption, integrity, and authentication with improved performance (1-RTT handshake, 0-RTT resumption)
-
DHCP automates IP configuration but has no authentication—rogue DHCP servers enable MITM attacks
-
Application layer protocols are where users interact with networks—and where many attacks occur
Self-Assessment
-
Comprehension: Why does DNS use both UDP (typically) and TCP? When is each used?
-
Application: A user complains their browser shows a certificate warning. What are the possible causes, and how would you troubleshoot?
-
What if: If an attacker compromises a recursive DNS resolver serving 100,000 users, what attacks become possible?
Review Questions
- What are the steps in DNS resolution, and what role does caching play?
- What are the differences between HTTP/1.1, HTTP/2, and HTTP/3?
- How does a TLS handshake establish secure communication?
- Why is certificate validation important, and what happens if it fails?
- What security risks does DHCP present, and how can they be mitigated?
- What advantages do DoH and DoT provide over traditional DNS?
Key RFCs
- RFC 1035 - Domain Names - Implementation and Specification
- RFC 8484 - DNS Queries over HTTPS (DoH)
- RFC 7858 - DNS over TLS (DoT)
- RFC 9110 - HTTP Semantics
- RFC 9113 - HTTP/2
- RFC 9114 - HTTP/3
- RFC 8446 - TLS 1.3
- RFC 2131 - Dynamic Host Configuration Protocol