Anonymity Engineering·2026-05-02·23 min read·advanced

Steganographic channels

DNS, ICMP, HTTP, and media-based covert channels; storage versus timing channels; and why protocol normalization breaks many hiding schemes.

The previous module showed how passive fingerprinting works at every layer of the stack. This module looks at the inverse problem: what does it take to hide the existence of communication, not just its content? Encryption protects what's in a message; steganography tries to conceal that a message exists at all. The two properties are different and require different defenses, and neither is the other.

Steganographic channels — also called covert channels — are mechanisms for embedding hidden communication inside legitimate-looking traffic. A DNS query that secretly carries data in its label structure; an ICMP ping that has a hidden payload in its data field; an HTTP request whose header order encodes bits; an image whose least-significant pixel bits contain a message. Each of these is a covert channel: from the network's perspective the traffic looks normal, but a knowing receiver can extract a hidden signal.

This module is the architectural treatment. We'll work through the storage-channel vs. timing-channel taxonomy that the foundational covert-channel literature uses, walk through DNS as the canonical practical example, look at ICMP and HTTP as additional substrates, briefly touch the network/file boundary where media steganography lives, examine why active wardens (protocol-normalizing intermediaries) defeat many channels, and end with the engineering reality that practical systems rarely rely on a single steganographic channel — they layer them with conventional crypto and treat the steganographic layer as one defense among several. The module stays academic; this is not an operational guide for bypassing network controls.

Prerequisites

dns-name-resolution-end-to-end — DNS is the most-discussed covert-channel substrate; you need to know how DNS queries are structured.
http-evolution-1-1-to-3 — for understanding the HTTP/HTTP-2 framing that creates application-layer hiding surfaces.
threat-models-for-network-anonymity — for understanding which adversaries steganographic defenses actually address.
os-and-tcpip-stack-fingerprinting — for awareness that hiding in protocol options has the same fingerprinting problem in reverse.

Learning objectives

Distinguish covert channels, steganographic channels, storage channels, and timing channels in networked systems.
Explain how DNS, ICMP, HTTP, and media payloads can carry hidden communication without inventing new transport protocols.
Compare capacity, stealth, reliability, and detectability across several common steganographic channel families.
Evaluate why most practical channels are fragile against protocol normalization and behavioral detection.

What makes a channel steganographic

The distinction between encryption and steganography is sharp:

Encryption addresses the content of communication. A message encrypted with a strong cipher is computationally indistinguishable from random bytes to anyone without the key. The attacker can see "Alice is sending bytes to Bob"; what those bytes mean is hidden.

Steganography addresses the existence of communication. A steganographic channel hides the message inside another medium (a "carrier") such that the carrier looks normal and the hidden message is invisible without knowing where to look. The attacker observing the network sees Alice doing normal things — sending DNS queries, browsing the web, sharing photos — and can't tell that any of those activities contains a hidden message.

The properties combine: a steganographically-hidden message is usually also encrypted, so even if the channel is detected, the content remains protected. But the security goals are different. Encryption gives confidentiality. Steganography gives unobservability — the property that an adversary can't distinguish "communication is happening" from "communication is not happening."

The classical covert-channel taxonomy (Lampson, 1973; Zander/Armitage/Branch, 2007) distinguishes:

Storage channels. Bits hidden in the value of some field, name, body, or ordering. Examples: DNS labels containing encoded data; ICMP payload bytes; HTTP header values; image pixel LSBs. The carrier transmits a value that's "unused" or "low-information" from the protocol's perspective; the receiver reads the value to recover the hidden bits.

Timing channels. Bits encoded in the timing or cadence of events rather than in their content. Examples: pause length between packets encoding 0 or 1; query-rate variations encoding a longer signal; ping-frequency modulation. The carrier itself is unmodified; the timing of the carrier's events carries the message.

Storage channels typically have higher capacity (you can stuff a lot of bits into a 32-byte field) but are more easily detected (if anyone looks at the field, they may notice it doesn't look "normal"). Timing channels have lower capacity (a few bits per second is typical) but can be harder to detect (unusual timing patterns are subtle and easy to miss in noisy networks).

Real systems often combine both: timing-channel control bits to coordinate, storage-channel payload bits for bulk data.

Storage channels versus timing channels

Reading the literature, "storage channel" and "timing channel" cover different attack-defense considerations.

Storage-channel design questions:

Which field carries the data? Some fields are unused by definition (reserved bits in protocol headers); some are theoretically used but most receivers ignore them (DNS TXT records of unusual length); some are user-controlled (URL paths, label values, header values).
How much capacity per carrier event? A DNS label can hold up to 63 bytes; a TCP option might hold 4-40 bytes; an HTTP header value is essentially unlimited. The choice trades capacity against detectability — bigger carriers can hold more data but stand out more.
How is the data encoded? Base32, base64, custom encoding, or even encoding choice itself as a side channel. Base32 is common because most DNS-label parsers accept base32 characters.
How is the receiver authenticated? Anyone observing the channel can attempt to extract data; the receiver needs to prove identity to use it. Usually this is solved by encrypting the data before steganographic embedding, so only the intended receiver can decrypt.

Timing-channel design questions:

What event provides the timing reference? Could be packet inter-arrival times, TCP retransmits, query rates, or anything else with measurable cadence.
How are bits encoded in timing? Common: long-pause = 1, short-pause = 0; or pause-bin assignment (each of N pause durations encodes log2(N) bits); or modulation of a periodic carrier.
What's the data rate? Typically very low — a few bits per second for safe channels. Higher rates risk detection.
How is the channel synchronized? Sender and receiver need a clock alignment; timing-channel protocols often start with a known synchronization preamble.

The detection picture differs too:

Storage-channel detection: Look at the suspect fields. Are values unusually high-entropy? Out of distribution? Patterned in ways that match a known encoding? Detection often requires inspection of payloads, which scales poorly to massive traffic but is feasible for targeted analysis.
Timing-channel detection: Statistical analysis of timing distributions. Inter-arrival times that don't match the expected distribution for the protocol may indicate timing-channel use. This is harder than storage-channel detection — natural network jitter introduces baseline variance — but achievable with enough observation.

DNS as a covert substrate

DNS is the canonical practical covert channel substrate, for both technical and operational reasons.

Technical reasons:

Each DNS query carries a domain name. The name has structure: dot-separated labels, each up to 63 bytes, total up to 255 bytes. Within these constraints, almost anything is allowed character-wise.
DNS responses can carry various record types, each of which has its own payload. TXT records can hold arbitrary strings up to several hundred bytes; CNAME records carry names; NULL records (rare but exist) hold raw bytes.
DNS recurses through resolvers transparently. A query for xxx.attacker-domain.example.com issued by a client gets passed up the DNS hierarchy until it reaches the authoritative nameserver for attacker-domain.example.com. The attacker controls that nameserver and reads the queries; the response goes back through the same recursion.
The DNS protocol is request-response, which gives the channel natural request-reply semantics.

Operational reasons:

DNS is allowed almost everywhere. Networks that block direct outbound TCP/UDP often allow DNS (otherwise the network barely works). Captive portals, hotel WiFi, corporate firewalls — all typically allow DNS.
DNS traffic is voluminous and noisy. A normal user generates many DNS queries per minute. Hiding additional queries among them is plausible.
DNS infrastructure is hard to inspect deeply. Recursive resolvers see queries; few log them in detail; and the encryption-of-DNS movement (DoH, DoT) makes the queries opaque to network observers.

The DNS tunneling pattern:

Client wants to send "secret data" to Attacker.
1. Client base32-encodes "secret data" into label-friendly form: "ONSWG4TFOQQHO33SNRSA===="
2. Client splits the encoded string into label-sized chunks and constructs:
   ONSWG4TFOQQHO33SNRSA.attacker-domain.example.com
3. Client sends a DNS A-record query for that name.
4. Local recursive resolver gets the query, doesn't have it cached, recurses.
5. Eventually the query reaches the authoritative nameserver for attacker-domain.example.com,
   which is run by the attacker.
6. The attacker's nameserver decodes the label, recovers "secret data", and returns
   some innocent-looking response (e.g., A record 192.0.2.1).
7. To send a reply, the attacker can encode response bytes in the IP returned (limited
   capacity per query), or in a TXT record returned, or signal that the next query
   should fetch the next chunk.

The channel works. It's also detectable. Defensive observations:

Query rate. Steganographic DNS often produces unusual query rates — very high (when transmitting bulk data) or very regular (timing channels). Normal user DNS is bursty around webpage loads and otherwise quiet.
Label entropy. Encoded labels look like random base32 strings. Normal DNS labels are domain names (low entropy, recognizable words). High-entropy labels are a strong signal.
Subdomain count. Steganographic channels generate many subdomains under one base. Normal users hit a few popular domains repeatedly. A spike in queries to many subdomains of one base is suspicious.
Time correlation. A user's DNS activity correlated with another visible activity (a particular file being modified, a USB device being inserted) suggests covert exfiltration.
Response patterns. Attacker-controlled nameservers often return unusual response patterns (always the same IP, or IPs from a small set, or unusual TTLs).

Modern DNS-monitoring tools (Cisco's Umbrella, OpenDNS, enterprise DNS analyzers) flag many of these patterns. DNS tunneling for casual exfiltration is detectable; DNS tunneling for sophisticated covert operations requires more careful design (rate limiting, mimicking real-user patterns, using established benign-looking domains).

The encryption-of-DNS movement (DoH and DoT — see doh-vs-dot-leak-comparison) helps in one sense and hurts in another for steganography. DoH/DoT hides the queries from network observers, so the network can't pattern-match labels. But the resolver still sees the queries; the recipient is now the resolver operator (Cloudflare, Google, etc.), who can implement their own detection. The channel moved; it didn't disappear.

ICMP and utility-protocol abuse

ICMP — the protocol for ping, traceroute, error messages — is another tempting substrate. Why:

Most networks allow some ICMP (echo request/reply for ping, destination-unreachable for routing diagnosis).
ICMP echo messages have a Data field that the protocol doesn't use for any specific purpose. The receiver echoes back what was sent. This is a perfect storage channel — arbitrary bytes go in, arbitrary bytes come out.
ICMP is rarely deeply inspected. Many security tools focus on TCP/UDP application traffic and treat ICMP as low-importance.
ICMP has its own connectionless model that can be embedded in normal-looking traffic patterns.

The ICMP tunneling pattern:

Client wants to send data to Attacker.
1. Client constructs an ICMP echo request packet to a server controlled by Attacker.
2. The Data field of the echo request contains encrypted client-to-attacker data.
3. The packet traverses the internet; at some hops, ICMP may be filtered, but typically
   echo gets through.
4. Attacker's server receives the echo request, extracts the data from the Data field.
5. Attacker constructs an ICMP echo reply with their own data in the Data field.
6. Reply goes back to Client.

Capacity: an ICMP packet can be up to MTU size (1500 bytes); each can carry around 1400 bytes of payload after headers. A modest data rate (10 pings per second) gives 14 KB/sec — enough for command-and-control or low-bandwidth exfiltration.

Defensive observations:

ICMP rate. Normal ICMP is sparse (a few pings per session; some traceroutes). Continuous ICMP echo traffic is suspicious.
ICMP payload entropy. Normal ICMP echo data is often a known pattern (e.g., the ASCII characters used by classic ping implementations). Encrypted payloads have high entropy and don't match the known patterns.
ICMP destination patterns. A user pinging the same IP frequently for days, especially an IP that doesn't correspond to any service the user uses, is suspicious.
Asymmetry. ICMP echo is request-reply. A user generating echoes to one IP that always responds is a complete bidirectional channel; a security tool may flag this asymmetric utility.

Modern firewalls increasingly drop ICMP echo by default (a controversial choice from a network-engineering perspective, since traceroute and ping are useful diagnostic tools); enterprise tools track ICMP volumes per host. ICMP tunneling exists in security-research and red-team contexts but is rarely used for serious operational covert channels because it's easy to detect once a defender knows to look.

HTTP and application-layer hiding

HTTP — and HTTPS, which is HTTP over TLS — is the most volume-rich protocol on the internet. Hiding data in HTTP traffic puts the steganographic channel in the largest possible carrier, with corresponding plausible-deniability benefits.

The hiding surfaces in HTTP:

Headers. HTTP allows arbitrary header names and values (within syntactic limits). Custom headers (X-Custom-Data: <encoded payload>) can carry data. Header order can encode bits.
Cookie values. Servers can set cookies with arbitrary values; the user-agent sends them back. A cookie with encoded data round-trips through legitimate-looking activity.
URL path. Path components can encode data (e.g., /api/v1/<encoded>) for systems that ignore unknown paths or accept many.
Query parameters. GET-request parameters carry arbitrary values.
Request bodies. POST bodies can be anything; encoding data in form bodies or multipart attachments is straightforward.
Response bodies. Servers can return arbitrary content; a "normal" looking response with hidden data in HTML comments or invisible-CSS-styled text round-trips.
Resource-name channels. The pattern of which resources are requested (which images, which JS files, in what order) can encode data without modifying any individual resource.

Capacity: very high. An HTTP request can carry kilobytes of data in custom headers and bodies; rates can match the user's normal browsing rates without drawing attention.

Stealth: depends on how carefully the hidden data mimics normal traffic patterns. A custom header with high-entropy payload stands out under inspection; encoded data in URL paths must look like legitimate paths to avoid notice.

Defensive observations:

TLS terminating proxies and CDNs see the cleartext. Behind a TLS terminating intermediary (most enterprises with content inspection, most CDNs with Web Application Firewall features), hidden data in HTTP is fully inspectable.
Request patterns. Unusually frequent requests to a specific destination, especially a destination not associated with normal user activity, is suspicious.
Header anomalies. Custom headers with names/values not used by legitimate clients are flagged.
Volume. Bulk steganographic transfer creates traffic-volume patterns that don't match normal browsing.

The HTTP/2 layer adds new hiding surfaces: SETTINGS frames, pseudo-header order, HPACK encoding choices. Mazurczyk et al.'s 2017 paper "Steganography of HTTP/2" demonstrated that even modern application protocols expose new hiding surfaces faster than defenders can normalize them.

The general HTTP-steganography insight: HTTP is the most hidden-data-friendly internet protocol because its surface is so large. It's also the most-watched protocol because of its prevalence and importance. The arms race is active.

Media and file steganography at the edge of networking

Strictly speaking, hiding data in image pixels (LSB steganography) is file-level steganography, not network. But the boundary is fuzzy: an image carried as an HTTP response, an attachment in an email, or a profile picture on a social media platform is delivered over the network. So media steganography is part of the broader steganographic ecosystem.

The classic technique:

Least-significant-bit (LSB) image steganography: Modify the lowest bit of each pixel's color channel to encode hidden data. A 1024x768 RGB image has 1024×768×3 = ~2.4 million color channels; with 1 bit hidden per channel, that's ~300 KB of hidden capacity in a single image. Visually, the modification is imperceptible — the lowest bit affects one of 256 brightness levels per channel.

Audio steganography: Similar techniques for audio files. Hide bits in least-significant samples; modulate at frequencies humans can't hear.

Video steganography: Same idea applied to video frames; massive capacity but more vulnerable to compression losses.

Why media steganography matters for network channels: the modified files travel over normal protocols. Sending a steganographically-modified image as an HTTP response, an email attachment, or a Discord avatar uses standard application protocols; the steganography is at the file level, not the protocol level. This bypasses many network-layer defenses.

Detection: complicated. Modern image steganography defenses use steganalysis — statistical techniques that look for the patterns LSB modification leaves in pixel distributions. Sophisticated defenses can detect LSB modification in 10-30% of pixels altered; below that threshold, detection is hard. The arms race continues; specific defenses are tuned to specific algorithms.

Detection and active wardens

The covert-channel literature distinguishes between passive wardens (observers who watch but don't modify traffic) and active wardens (intermediaries who normalize, rewrite, or reject traffic). Passive wardens can detect channels with statistical analysis; active wardens can destroy them by normalizing protocol elements.

Examples of active wardens at work:

DNS recursive resolvers that normalize labels, cap subdomain counts, or limit query rates per domain. A steganographic DNS channel that depends on rapid-fire querying gets throttled.
HTTP-rewriting proxies that strip custom headers, normalize header order, recompress images. Hidden data in custom headers disappears at the proxy; LSB-encoded image data may be lost during recompression.
TLS-terminating intermediaries (CDNs, content-inspection devices) that re-establish TLS connections and inspect plaintext. Steganographic data in HTTPS bodies is exposed to the inspector.
Image-resizing CDNs that automatically resize uploaded images. LSB-encoded data is destroyed by resize-and-recompression.
Email gateways that strip attachments not matching policy or recompress media.

The principle: protocol freedom is the covert channel's oxygen. Anywhere in the path that normalizes, the channel narrows or breaks. Defenders' best moves are normalization at chokepoints; covert-channel designers try to find paths that don't have aggressive normalizers.

A particular threat: traffic normalization at every layer. Imagine a hostile network operator who:

Drops all ICMP except destination-unreachable.
Forces all DNS queries through a normalizing resolver that strips long subdomains.
Forces all HTTP through a content-inspection proxy that strips custom headers.
Decompresses and recompresses all images.
Strips email attachments outside an allowlist of types.

Almost no covert channel survives this comprehensive normalization. The cost to the operator is breakage of legitimate uses (some apps need ICMP, some users send long subdomain names, some sites use custom headers, some images don't compress well). The trade-off is real and frequently made differently in different environments.

Why real systems rarely rely on one channel alone

The reliability and capacity constraints of any single steganographic channel are tight. Real operational systems use steganographic channels as one layer of a broader transport stack:

Encrypted payload over a steganographic carrier. The hidden data is itself encrypted, so the steganographic layer's job is just to hide the existence; the content protection is from the cryptography. If the channel is detected, the content remains protected.
Multiple channels in parallel. Use both DNS and HTTP simultaneously; the reliability of either alone is poor, but the combined system survives one channel being normalized.
Fallback strategies. Try a high-bandwidth channel first; fall back to lower-bandwidth backup channels if the primary is detected.
Steganographic channels for control, not bulk data. Use covert channels for command-and-control signaling that requires only a few bytes per minute; use a separate (possibly more conventional) channel for bulk data exchange once established.

The frame: steganography contributes unobservability — making the existence of communication harder to detect. It does not provide bulk-bandwidth or content protection. Modern covert systems combine steganographic channels with conventional encrypted transports, treating the steganographic layer as one defense among several.

The censorship-evasion world (covered in Track 6) uses related ideas — protocol mimicry, traffic shaping to look like normal-application traffic — but with different goals. Steganographic channels primarily serve covert exfiltration and command-and-control; censorship evasion serves bulk-traffic delivery in hostile environments. Both face protocol normalization pressure; both layer with conventional crypto. The next track (active-probing-defense) covers the specific techniques nation-state firewalls use to detect circumvention traffic, which overlaps with covert-channel detection but has its own terminology and tactics.

Hands-on exercise

Encode data into mock DNS labels.

Tools: python3. Runtime: 15 minutes.

import base64

def encode_message_to_dns_labels(message: str, base_domain: str,
                                  label_max: int = 50) -> list[str]:
    """
    Encode a string into DNS-compliant labels under a base domain.
    Returns a list of fully-qualified names to query in sequence.
    """
    # Base32 keeps things to letters and digits, RFC-1035-friendly.
    encoded = base64.b32encode(message.encode()).decode().rstrip("=")

    # Each label can be up to 63 characters; conservatively use 50.
    chunks = [encoded[i:i + label_max] for i in range(0, len(encoded), label_max)]

    # Each query carries one chunk plus a sequence prefix.
    names = []
    for i, chunk in enumerate(chunks):
        # "01-CHUNK.basedomain", "02-CHUNK.basedomain", ...
        names.append(f"{i:02d}-{chunk.lower()}.{base_domain}")
    return names

msg = "secret data hidden in DNS"
names = encode_message_to_dns_labels(msg, "ex.attacker-controlled.example")

print(f"Original: {msg!r}")
print(f"Encoded into {len(names)} DNS query name(s):")
for n in names:
    print(f"  query: {n}")
print()
print(f"Total label bytes per query: ~{len(names[0])}")
print(f"Effective bytes per query (after base32 expansion): "
      f"~{len(names[0]) * 5 // 8}")
print(f"To transfer 1 KiB you need: ~{1024 // (len(names[0]) * 5 // 8)} queries")

Run it. Observations:

The encoded labels look like random base32 strings, not normal domain names.
A short message becomes one or two queries; a 1 KiB transfer needs ~25-50 queries.
The base domain is repeated in every query, making the channel obvious if anyone aggregates by domain.

Stretch: estimate how many DNS queries per second you'd need to exfiltrate 1 MB of data. (Answer: depends on per-query capacity, but at ~30 bytes per query, 1 MB = ~35,000 queries. At a normal-user query rate of 10/sec, that's an hour of constant DNS traffic — extremely conspicuous.)

Reason about normalization.

Tools: notes. Runtime: 10 minutes.

For each of the following protocols, list what an active warden could rewrite or reject to shrink the covert-channel space:

DNS:

Reject queries with high-entropy labels.
Cap query rate per source per domain.
Force all DNS through a single recursive resolver that strips long subdomains.
Refuse to resolve subdomains beyond a depth limit.
Block queries to TXT records or unusual record types.

ICMP:

Drop all echo (ping) requests/responses.
Limit ICMP rate per source.
Require ICMP from source-IPs to destinations the source has recently TCP'd to.
Strip ICMP payload data (replace with zeros).

HTTP:

Strip custom headers (any header not on an allowlist).
Normalize header order.
Force TLS termination and re-encryption to allow content inspection.
Recompress images and other media to standard formats.
Limit per-request payload size.

For each, identify what legitimate usage is broken:

DNS: long-subdomain CDNs (some legitimate use), TXT records for SPF/DKIM (legitimate).
ICMP: traceroute, MTU discovery, ping for diagnostics (all legitimate).
HTTP: custom-header authentication tokens, large file uploads, media-heavy sites (all legitimate).

The breakage is real. Aggressive normalization defeats covert channels but degrades legitimate use; the right level depends on the operator's threat model. Most operators don't do all of these because the cost of breakage outweighs the covert-channel concern.

Common misconceptions and traps

"Steganography is just encryption in disguise." The security goals are different. Encryption hides content; steganography hides existence. A channel that's both encrypted and steganographic provides both properties. Calling them the same misses the unobservability versus confidentiality distinction.

"DNS tunneling is invisible because DNS is everywhere." DNS is common, but high-entropy labels, unusual query rates, abnormal subdomain structures, and atypical response patterns all stand out under analysis. Modern DNS-monitoring tools flag many tunneling patterns. DNS tunneling for casual operations is detectable; for sophisticated operations it requires careful design.

"Any unused header field is a perfect covert channel." Many paths normalize or discard fields; even preserved fields may be statistically conspicuous. The "unused" assumption often breaks at the first proxy or middlebox.

"Timing channels require no bandwidth tradeoff." Encoding bits in timing typically lowers throughput substantially (a few bits per second is normal) and becomes fragile under network jitter that washes out the timing signal. Storage channels generally have higher capacity per overhead unit.

"One covert channel is enough for robust operations." Capacity, reliability, and detection-pressure constraints usually force fallback strategies or layered designs. Production covert systems combine multiple channels for redundancy and resilience.

"Active wardens can be defeated by encrypted payloads." Encryption protects the content of the hidden data but doesn't protect the carrier from normalization. A normalizing intermediary that strips custom headers or canonicalizes header order destroys the channel regardless of what's inside it.

"Steganography is illegal." Steganography itself isn't illegal in most jurisdictions; the legality depends on what's being communicated and to whom. Hiding personal information in images you share is generally fine; using steganographic channels for criminal command-and-control is not. Don't confuse legality of mechanism with legality of use.

"My corporate firewall doesn't do this." Many corporate firewalls do active normalization without making it visible to users. DNS forwarding through normalized resolvers, TLS-terminating proxies for content inspection, image-recompressing email gateways are all common in enterprise environments. The user often doesn't notice; the covert-channel designer does.

Wrapping up

Steganographic channels hide the existence of communication inside legitimate-looking carrier traffic. The classical taxonomy distinguishes storage channels (bits in field values) from timing channels (bits in event timing); both have their use cases and tradeoffs.

DNS, ICMP, HTTP, and media files are common substrates, each with its capacity, stealth, and detection profile. None is a complete answer; all are vulnerable to active wardens that normalize or strip protocol elements. Production systems use steganographic channels as one defense layer among several, layered with conventional encryption for content protection and with multiple parallel channels for redundancy.

The fundamental tension: protocol freedom is the covert channel's oxygen; protocol normalization is the active warden's tool. Network operators choose where to sit on the spectrum based on their threat models and their tolerance for legitimate-use breakage.

This module concludes Track 4 — Anonymity Engineering. Track 5 (Detection and Censorship) covers the active counterpart: how nation-state firewalls and other adversaries actively probe traffic to detect and block circumvention, and how circumvention systems respond. Track 6 (Evasion) covers the operational tactics — REALITY, naïveproxy, domain fronting, pluggable transports — that combine many of the ideas from Tracks 4 and 5 into deployed censorship-evasion systems.