Add attack surface review #006 — systematic enumeration of untrusted input entry points

docs/reviews/006-attack-surface-review.md

@@ -0,0 +1,657 @@
+---
+status: draft
+last_updated: 2026-06-14
+reviewed_code:
+  - src/server.rs
+  - src/proxy/handler.rs
+  - src/proxy/headers.rs
+  - src/proxy/body_limit.rs
+  - src/proxy/error.rs
+  - src/proxy/mod.rs
+  - src/tls/acceptor.rs
+  - src/tls/acme.rs
+  - src/tls/config.rs
+  - src/tls/redirect.rs
+  - src/rate_limit/mod.rs
+  - src/rate_limit/bucket.rs
+  - src/admin/socket.rs
+  - src/shutdown.rs
+  - src/config/static_config.rs
+  - src/config/dynamic_config.rs
+  - src/config/validation.rs
+  - src/config/mod.rs
+  - src/health.rs
+  - src/cli.rs
+  - src/main.rs
+  - src/utils.rs
+  - src/logging/mod.rs
+  - src/logging/format.rs
+reviewer: code-reviewer
+---
+
+# Attack Surface Review #006
+
+## Purpose
+
+Systematic enumeration of every point where untrusted input enters the reverse
+proxy, with analysis of where that input intersects with logic decisions. The
+goal is not to find specific vulnerabilities (see review #005 for that) but to
+map the entire attack surface so that current and future reviewers know where to
+focus adversarial attention.
+
+This review was motivated by the observation that Rust's memory model eliminates
+entire bug classes, meaning the remaining interesting surface is where
+**client-controlled data influences a decision or construction** — the "glue"
+layer between battle-tested components.
+
+---
+
+## Methodology
+
+Every code path that receives data from outside the process was traced from its
+entry point through to where it is consumed, transformed, or forwarded. Each
+path was classified by:
+
+- **Source**: Where the data originates (network, filesystem, OS signal, etc.)
+- **Entry point**: File and line where the data first enters our code
+- **Validation**: What checks are applied before the data is used
+- **Sink**: Where the data ends up (upstream connection, filesystem, URL
+  construction, routing decision, etc.)
+- **Risk**: How much control an attacker has and what the consequences are
+
+Findings are grouped by entry point category.
+
+---
+
+## Category 1: Incoming HTTPS/TLS Connections
+
+### 1.1 TCP Connection Accept
+
+**Source**: Network (any IP)
+**Entry**: `src/server.rs:67-68` — `tcp_listener.accept()`
+**Input**: Raw TCP SYN from any source
+**Validation**: OS TCP handshake only. No IP allowlist/denylist.
+**Sink**: TLS handshake
+**Risk**: None at this layer. Connection errors are logged and the loop
+continues. No resource limiting beyond OS TCP backlog.
+
+### 1.2 TLS ClientHello
+
+**Source**: Network (TLS ClientHello)
+**Entry**: `src/server.rs:83` — `tls_acceptor.accept(tcp_stream).await`
+**Input**: SNI hostname, cipher suites, ALPN protocols, TLS version range,
+client certificate (not requested — `with_no_client_auth()` at
+`tls/config.rs:62`)
+**Validation**:
+- Cipher suites restricted to 7 approved suites (`tls/config.rs:14-22`)
+- Protocol versions limited to TLS 1.2/1.3 (`tls/config.rs:9,61`)
+- Key exchange limited to X25519, SECP256R1, SECP384R1 (`tls/config.rs:28`)
+- Failed handshakes produce a warn log and connection drop (`server.rs:85-88`)
+**Sink**: ALPN detection at `server.rs:91-92`, then HTTP handler
+**Risk**: **SNI hostname is not validated at the TLS layer.** Any SNI value
+completes the handshake. Host-based routing only happens at the HTTP layer
+(`handler.rs:39-55`). This means TLS connections for arbitrary hostnames are
+accepted and complete before receiving a 404, potentially leaking certificate
+information (which certificate is served, what names it covers). This is
+standard for multi-host proxies but worth noting.
+
+### 1.3 ALPN Protocol Selection
+
+**Source**: Network (TLS ClientHello ALPN extension)
+**Entry**: `src/server.rs:91-92` — `tls_stream.get_ref().1.alpn_protocol()`
+**Input**: ALPN protocol identifier bytes (e.g., `b"h2"`, `b"http/1.1"`)
+**Validation**: Binary comparison only: `alpn == Some(b"h2")` selects h2;
+anything else falls through to the auto-detect builder (`server.rs:92-125`).
+No explicit rejection of unexpected ALPN values.
+**Sink**: Determines whether HTTP/2 or HTTP/1.1 handler is used
+**Risk**: Low. hyper handles unexpected ALPN values by falling back to HTTP/1.1
+semantics.
+
+### 1.4 HTTP/2 and HTTP/1.1 Request Streams
+
+**Source**: Network (HTTP frames over TLS)
+**Entry**: `src/server.rs:103-125` — hyper connection handlers
+**Input**: Full HTTP request stream (method, URI, headers, body)
+**Validation**: Delegated entirely to hyper's HTTP parser. No application-level
+validation of frame sizes, header counts, or connection settings beyond what
+hyper enforces.
+**Sink**: Axum router → proxy handler
+**Risk**: Medium. hyper is well-vetted, but the proxy applies no additional
+request validation layer (no header count limits, no total header size limits,
+no max URI length). These are defense-in-depth measures that proxies commonly
+implement.
+
+---
+
+## Category 2: HTTP Request Processing
+
+### 2.1 HTTP Method
+
+**Source**: Network (HTTP request line)
+**Entry**: `src/proxy/handler.rs:37` — `req.method().clone()`
+**Input**: HTTP method string (GET, POST, custom methods, etc.)
+**Validation**: None by the application. Method is cloned and forwarded to
+upstream as-is via `build_upstream_request` (`handler.rs:218-228`).
+**Sink**: Logged, forwarded to upstream
+**Risk**: Low. Hyper validates that the method is syntactically valid. Unusual
+methods (CONNECT, TRACE, etc.) are forwarded to upstream, which may or may not
+handle them. No method allowlist is applied.
+
+### 2.2 Request URI (Path + Query String) — **HIGHEST PRIORITY SURFACE**
+
+**Source**: Network (HTTP request line)
+**Entry**: `src/proxy/handler.rs:38` — `req.uri().path().to_string()`
+**Input**: Full request path and query string (e.g., `/api/users?foo=bar`)
+**Validation**:
+- `Uri::parse` provides structural validation in `build_upstream_uri()`
+  (`handler.rs:206-216`)
+- If URI parse fails, 502 is returned (`handler.rs:67-80`)
+- **No application-level sanitization** of:
+  - Path traversal sequences (`/../`, `/..%2f`)
+  - Double-encoded characters (`%252e%252e`)
+  - CRLF injection in query strings (`?foo=bar%0d%0aInjected: header`)
+  - Null bytes (`%00`)
+  - Unicode normalization differences
+**Sink**: Reconstructed as `scheme://upstream/path?query` and forwarded to
+upstream service
+**Risk**: **High.** This is the most important surface for adversarial
+analysis. The client's raw path and query are concatenated verbatim into the
+upstream URL. Whether this matters depends on the upstream, but a
+security-focused reverse proxy should normalize paths and reject or sanitize
+dangerous patterns. Specific attack vectors:
+
+- **Path traversal**: A request to `/../../../etc/passwd` would be forwarded
+  as `http://upstream:8080/../../../etc/passwd`. Whether this reaches
+  sensitive files depends entirely on the upstream.
+- **CRLF injection**: A query string containing `%0d%0a` could inject
+  additional headers or HTTP content in the upstream request if the upstream
+  or an intermediary interprets raw CR/LF in query parameters.
+- **Query string smuggling**: The `build_upstream_uri` function concatenates
+  path and query without normalization. Ambiguous URLs like
+  `//evil.com%23@target` could potentially confuse upstream parsers.
+
+### 2.3 Host Header — Routing Decision Point
+
+**Source**: Network (HTTP Host header)
+**Entry**: `src/proxy/handler.rs:39-44`
+**Input**: Host header value or URI host component
+**Validation**:
+- Empty/missing Host → 400 Bad Request (`handler.rs:46-47`)
+- Host is used to look up site in routing table via `normalize_host()`
+  (`dynamic_config.rs:52-61`): strips port, lowercases, strips IPv6 brackets
+- Unknown host → 404 (`handler.rs:55`)
+- `to_str()` on the header value fails on non-ASCII/invalid bytes (implicit
+  validation by hyper)
+**Sink**: Routing decision (which upstream to proxy to)
+**Risk**: Low-Medium. The normalized host is used only for routing lookup, not
+for URL construction (upstream host comes from config). However:
+- **Unicode homoglyphs**: `normalize_host` lowercases but does not handle
+  Unicode confusables (e.g., `ⓔⓧⓐⓜⓟⓛⓔ.com` vs `example.com`). This is
+  mitigated by `to_str()` rejecting non-ASCII, so only ASCII hosts reach the
+  lookup.
+- **Very long hosts**: No length limit on Host header value before routing
+  lookup. A multi-megabyte Host header would be hashed for HashMap lookup.
+- **IPv6 bracket handling**: `normalize_host` strips brackets from
+  `[::1]:443` → `::1`. A malformed Host like `[invalid` would have brackets
+  stripped incorrectly, but would simply fail the routing lookup (404).
+
+### 2.4 All Other Client Request Headers
+
+**Source**: Network (HTTP request headers)
+**Entry**: `src/proxy/handler.rs:59-60` — `inject_proxy_headers()` and
+`remove_hop_by_hop()`, then `handler.rs:223-225` in `build_upstream_request()`
+**Input**: Complete set of HTTP headers sent by the client
+**Validation/Sanitization**:
+- **X-Forwarded-For is REPLACED** with actual client IP (not appended) —
+  prevents XFF spoofing (`headers.rs:28-32`)
+- **X-Real-IP is SET** to actual client IP (`headers.rs:26`)
+- **X-Forwarded-Proto is SET** to "https" (`headers.rs:37-40`)
+- **Hop-by-hop headers are REMOVED** (`headers.rs:4-13`): connection,
+  keep-alive, proxy-authorization, proxy-authenticate, te, trailers,
+  transfer-encoding, upgrade
+- **All other headers are forwarded as-is** (`handler.rs:223-225`)
+**Sink**: Forwarded to upstream service
+**Risk**: Medium. No allowlist or additional blocklist is applied beyond
+hop-by-hop headers. Potential concerns:
+- **Request smuggling via ambiguous headers**: Headers like
+  `Transfer-Encoding: chunked` on a HTTP/1.0 request, or duplicate
+  `Content-Length` values, could create discrepancies between how hyper parses
+  the request and how the upstream interprets it. Hyper normalizes these, but
+  the gap between hyper's parsing and the upstream's parsing is where request
+  smuggling lives.
+- **Header injection via upstream URL**: Not applicable here since the
+  upstream URL is constructed from config values, not client input (except
+  path/query, covered in 2.2).
+
+### 2.5 Request Body
+
+**Source**: Network (HTTP request body)
+**Entry**: `src/proxy/body_limit.rs:14-45` — `body_limit_middleware`
+**Input**: Arbitrary request body bytes
+**Validation**:
+- **Content-Length early rejection**: If `Content-Length` header value exceeds
+  `limit_bytes`, 413 is returned without reading the body (`body_limit.rs:30-38`)
+- **Invalid Content-Length**: Silently ignored via `if let Ok` chains
+  (`body_limit.rs:31-32`). Streaming limit applies instead.
+- **Negative Content-Length**: Cannot exist — `u64::parse` rejects negative
+  strings.
+- **Streaming body limit**: `Limited::new(body, limit as usize)` enforces the
+  limit during streaming for chunked/HTTP2 requests (`body_limit.rs:41`)
+- Default limit: 100 MiB (`body_limit.rs:12`)
+**Sink**: Forwarded to upstream as-is
+**Risk**: Low. Body size is properly bounded. No content-type validation or
+body content inspection — the proxy treats the body as opaque bytes, which is
+correct for a reverse proxy.
+
+---
+
+## Category 3: HTTP Redirect Listener
+
+### 3.1 Host Header (Redirect)
+
+**Source**: Network (HTTP Host header on plaintext listener)
+**Entry**: `src/tls/redirect.rs:41-46`
+**Input**: Host header value from unencrypted HTTP request
+**Validation**:
+- Empty/missing Host → 400 (`redirect.rs:48-49`)
+- Port is stripped via `strip_port_from_host()` (`utils.rs:1-13`)
+- **`HeaderValue::from_str()` validates** the constructed Location header value
+  at `redirect.rs:69`. Rejects non-ASCII and null bytes.
+**Sink**: Constructed into `Location: https://{host}:{port}/{path}` redirect
+response
+**Risk**: **Medium.** This is the classic open redirect / header injection
+vector. The Host header is directly interpolated into the Location response
+header. While `HeaderValue::from_str()` rejects bytes that would break HTTP
+framing (null bytes, non-ASCII), it does **not** reject:
+- Hosts with embedded CRLF (`\r\n`) — but `to_str()` should fail on these
+  since header values can't contain raw CR/LF per HTTP spec
+- Numeric IP addresses pointing to internal services (open redirect to
+  `127.0.0.1`)
+- Hosts that look like different origins (`evil.example.com` when the proxy
+  serves `example.com`)
+
+The `HeaderValue::from_str()` check at line 69 is the primary defense against
+header injection. If `to_str()` on the Host header properly rejects `\r\n`,
+this is safe. **This should be explicitly tested.**
+
+### 3.2 Request URI Path/Query (Redirect)
+
+**Source**: Network (HTTP request URI on plaintext listener)
+**Entry**: `src/tls/redirect.rs:52-53`
+**Input**: Request path and query string
+**Validation**:
+- Paths starting with `/.well-known/acme-challenge/` return 404 instead of
+  redirect (`redirect.rs:55-65`)
+- Path normalization: empty or non-`/`-prefixed paths get `/` prepended
+  (`redirect.rs:27-30`)
+- `HeaderValue::from_str()` final safety check on Location value
+**Sink**: Concatenated into redirect Location URL via `build_redirect_url()`
+**Risk**: Low-Medium. The path is appended to the redirect URL. CRLF in the
+path could theoretically inject headers if not properly rejected, but
+`HeaderValue::from_str()` provides a final safety net.
+
+---
+
+## Category 4: Config File Input
+
+### 4.1 Config File Read (Startup)
+
+**Source**: Filesystem (TOML config file)
+**Entry**: `src/cli.rs:49` — `std::fs::read_to_string(config_path)`
+**Input**: Entire contents of the config file
+**Validation**:
+- File must exist and be readable
+- Content parsed as TOML via `serde::Deserialize` — enforces types and required
+  fields
+- 20+ business-rule validations in `src/config/validation.rs:78-273`
+**Sink**: Parsed into `StaticConfig` + `DynamicConfig`, used for all runtime
+decisions (bind addresses, TLS, upstream targets, rate limits, etc.)
+**Risk**: Medium. Config is trusted input (operator controls it), but:
+- **Config file TOCTOU**: Between validation and use, the file could be
+  replaced (low practical risk since startup reads it once)
+- **Upstream values in config** are validated for format (`host:port`) but
+  could point to internal services, creating SSRF-like risks if an attacker
+  can modify the config file
+
+### 4.2 Config File Read (Reload — SIGHUP)
+
+**Source**: Filesystem (same config file, re-read on SIGHUP)
+**Entry**: `src/shutdown.rs:88` — `tokio::fs::read_to_string(config_path).await`
+**Input**: Entire contents of the config file at reload time
+**Validation**: Same `FullConfig::parse()` + `validate()` pipeline. Failed
+  parse/validation retains old config (failsafe).
+**Sink**: Swapped into `ArcSwap<DynamicConfig>` and `ArcSwap<StaticConfig>`
+**Risk**: Medium. **TOCTOU between reads**: If another process is writing the
+  config file at the exact moment SIGHUP triggers a read, a partial file could
+  be read. The parse would likely fail (invalid TOML), triggering a reload
+  error, which is safe. But a carefully timed write could produce a valid-but-
+  malicious partial file. This is the same issue noted in review #005 (W2).
+
+### 4.3 Config File Read (Reload — Admin Socket)
+
+**Source**: Filesystem (same config file, re-read on admin "reload" command)
+**Entry**: `src/admin/socket.rs:257`
+**Input**: Same as 4.2
+**Validation**: Same pipeline, plus reload mutex serialization
+**Risk**: Same as 4.2. Additionally, the admin socket is unauthenticated
+(review #005, C2), so any local user can trigger a config re-read.
+
+### 4.4 Config Values Used in URL Construction
+
+**Source**: Filesystem (site `upstream` and `upstream_scheme` from config)
+**Entry**: `src/proxy/handler.rs:62-64`
+**Input**: `upstream` (e.g., `"127.0.0.1:8080"`) and `upstream_scheme`
+  (e.g., `"http"`) from config
+**Validation**: `is_valid_upstream()` validates `host:port` format at config
+  time (`validation.rs:306-332`). `upstream_scheme` must be `"http"` or
+  `"https"` (`validation.rs:251-256`).
+**Sink**: Constructed into `format!("{}://{}", upstream_scheme, upstream)` at
+  `handler.rs:64`, then used as base URL for all proxied requests
+**Risk**: Low. Values come from trusted config, not client input. However, if
+  config is compromised, `upstream` could point to an attacker-controlled
+  service (SSRF via config).
+
+---
+
+## Category 5: TLS / ACME
+
+### 5.1 ACME TLS-ALPN-01 Challenge
+
+**Source**: Network (TLS ClientHello with ALPN `acme-tls/1`)
+**Entry**: `src/tls/acceptor.rs:25-29`
+**Input**: TLS connection using ALPN `acme-tls/1` during certificate validation
+**Validation**: Handled entirely by `rustls_acme` library. No application code
+  processes the challenge request.
+**Risk**: Low. Delegated to well-audited library.
+
+### 5.2 ACME HTTP-01 Challenge (Redirect Listener)
+
+**Source**: Network (HTTP request to `/.well-known/acme-challenge/`)
+**Entry**: `src/tls/redirect.rs:55-65`
+**Input**: HTTP request path
+**Validation**: The redirect listener **returns 404** for all ACME challenge
+  paths. It does NOT serve challenge responses.
+**Risk**: None. The proxy explicitly does not handle HTTP-01 challenges.
+
+### 5.3 ACME Certificate Cache
+
+**Source**: Filesystem (cached certificates in `acme_cache_dir`)
+**Entry**: `src/tls/acme.rs:36` — `DirCache::new(self.cache_dir.clone())`
+**Input**: Previously cached ACME certificates and account data from disk
+**Validation**: Handled by `rustls_acme`. Cache load failures are logged.
+  Invalid cached certs produce `CachedCertParse` errors.
+**Risk**: Low. If an attacker can write to `acme_cache_dir`, they could
+  substitute a cached certificate. This would be detected by ACME validation
+  on next renewal, but could allow temporary MITM.
+
+### 5.4 ACME Directory URL
+
+**Source**: Config file
+**Entry**: `src/tls/acme.rs:29-33`
+**Input**: The `acme_directory` config value — can be `"production"`,
+  `"staging"`, or an arbitrary URL string
+**Validation**: No URL format validation. Any string that isn't `"production"`
+  or `"staging"` is used as a raw URL.
+**Risk**: Medium. If config is compromised, an attacker could point the ACME
+  client at a malicious server, potentially obtaining fraudulent certificates
+  for the configured domains.
+
+### 5.5 Manual Certificate and Key Files
+
+**Source**: Filesystem (PEM certificate and key files)
+**Entry**: `src/tls/config.rs:33-53` — `load_certs()` and `load_private_key()`
+**Input**: PEM-encoded certificate chain and private key from disk
+**Validation**:
+- File must be readable
+- PEM must parse as certificates/key
+- At least one certificate must be present
+- Config validation checks file existence at startup
+- **Certificate expiry, chain validity, and key-match are NOT checked at load
+  time** — left to rustls runtime errors
+**Risk**: Low for external attack. Expired or mismatched certs will cause
+  runtime TLS errors. The risk is operational (service disruption from
+  expired certs that could have been caught at startup).
+
+---
+
+## Category 6: Admin Interface
+
+### 6.1 Admin Socket Connections
+
+**Source**: Local process (Unix domain socket)
+**Entry**: `src/admin/socket.rs:110` — `listener.accept()`
+**Input**: Unix domain socket connections from local processes
+**Validation**: No authentication or peer credential checking. Any process with
+  filesystem access to the socket can connect.
+**Risk**: Covered extensively in review #005 (C2). Being replaced by
+  authenticated HTTP endpoint per the architectural recommendation in that
+  review.
+
+### 6.2 Admin Command Input
+
+**Source**: Local process (text sent over Unix socket)
+**Entry**: `src/admin/socket.rs:167-252` — `handle_connection()`
+**Input**: Text command string (expected: "reload", "status", or empty/unknown)
+**Validation**:
+- 4 KiB read limit via `.take(4096)` (`socket.rs:171`)
+- 5-second read timeout (`socket.rs:174-175`)
+- Newline termination required
+- Command allowlist: only "reload" and "status" are recognized
+- Unknown commands echo input back: `"unknown command: {input}"` (minor
+  information disclosure)
+**Risk**: Covered in review #005 (C3, W1).
+
+---
+
+## Category 7: OS Signals
+
+### 7.1 SIGTERM/SIGINT
+
+**Source**: OS kernel (signal delivered to process)
+**Entry**: `src/shutdown.rs:51` — `Signals::new([SIGTERM, SIGINT, SIGHUP])`
+**Input**: Signal number
+**Validation**: Only registered signals are processed. SIGTERM/SIGINT trigger
+  graceful shutdown.
+**Risk**: None. Signals carry no data payload.
+
+### 7.2 SIGHUP (Config Reload Trigger)
+
+**Source**: OS kernel
+**Entry**: `src/shutdown.rs:70-72` — calls `handle_sighup_reload()`
+**Input**: SIGHUP signal triggers re-reading config file from disk
+**Validation**: Full config validation pipeline on the re-read config. Failsafe:
+  old config is retained on failure.
+**Risk**: See 4.2. The signal itself is harmless; the risk is in the
+  subsequent filesystem read.
+
+---
+
+## Category 8: Environment and CLI
+
+### 8.1 CLI Arguments
+
+**Source**: Process invocation (command line)
+**Entry**: `src/cli.rs:35-37` — `Cli::parse()` (clap)
+**Input**: `--config` (path string), `--validate` (flag),
+  `--allow-wildcard-bind` (flag)
+**Validation**: Clap enforces type constraints. Config path not validated for
+  existence until `load_config()` is called.
+**Risk**: Low. CLI args are trusted input (operator controls them).
+
+### 8.2 NOTIFY_SOCKET (systemd)
+
+**Source**: Environment variable
+**Entry**: `src/main.rs:24` — `std::env::var("NOTIFY_SOCKET")`
+**Input**: Path to systemd notification socket
+**Validation**: Only checked for existence. `sd_notify::notify()` handles the
+  socket communication.
+**Risk**: None. Standard systemd protocol.
+
+### 8.3 RUST_LOG (Tracing Filter)
+
+**Source**: Environment variable
+**Entry**: `src/logging/mod.rs:25` — `EnvFilter::from_default_env()`
+**Input**: Tracing filter directives (e.g., `RUST_LOG=debug`)
+**Validation**: Handled by `tracing_subscriber`. Invalid directives are silently
+  ignored.
+**Risk**: Low. Could be used to increase log verbosity, potentially leaking
+  sensitive request data in logs. Only exploitable by someone who can set
+  environment variables (typically operator-level access).
+
+---
+
+## Category 9: Health Check Endpoint
+
+### 9.1 Health Check Request
+
+**Source**: Network (localhost:9900 only)
+**Entry**: `src/health.rs:9` — `health_handler()`
+**Input**: HTTP GET request to `/health`
+**Validation**: Binds only to 127.0.0.1 (`health.rs:20`). Only `/health` path
+  is routed. No request body, headers, or parameters are read. Returns 200 OK
+  with empty body.
+**Risk**: None. Minimal surface.
+
+---
+
+## Category 10: Rate Limiter
+
+### 10.1 Client IP for Rate Limiting
+
+**Source**: Network (TCP connection remote address via ConnectInfo)
+**Entry**: `src/rate_limit/mod.rs:66-69`
+**Input**: Client IP address from the TCP layer (kernel-provided)
+**Validation**:
+- Uses `ConnectInfo<SocketAddr>` (kernel-provided, not client-supplied
+  X-Forwarded-For) — prevents IP spoofing
+- If no ConnectInfo is present, request is rejected with 429 (`mod.rs:71-72`)
+- IPv6 addresses are normalized to /64 prefix (`bucket.rs:50-68`) to prevent
+  /128 evasion
+**Sink**: Used as token bucket key for rate limiting decisions
+**Risk**: Low. The IP comes from the kernel, not from client headers. IPv6 /64
+normalization prevents address expansion attacks.
+
+---
+
+## Category 11: Upstream Response
+
+### 11.1 Upstream Response Headers
+
+**Source**: Network (upstream service response)
+**Entry**: `src/proxy/handler.rs:130-131`
+**Input**: All HTTP response headers from upstream
+**Validation/Sanitization**:
+- Hop-by-hop headers are removed (`handler.rs:131`)
+- The `Server` header is explicitly removed (`handler.rs:135`)
+- **All other response headers are forwarded to the client as-is**
+**Sink**: HTTP response sent to the client
+**Risk**: Low-Medium. Headers like `X-Powered-By`, `X-AspNet-Version`, etc.
+  that could leak upstream technology stack information are forwarded. This is
+  an information disclosure risk, not a functional vulnerability.
+
+### 11.2 Upstream Response Body
+
+**Source**: Network (upstream service response body)
+**Entry**: `src/proxy/handler.rs:136-137`
+**Input**: Arbitrary response body bytes from upstream
+**Validation**: **None.** No size limit on upstream response body. Streamed
+  directly to the client.
+**Sink**: HTTP response body sent to the client
+**Risk**: Low. The proxy streams the response through without buffering the
+  entire body (axum/hyper streaming model), so memory impact is bounded by
+  chunk size, not total body size. However, there is no response body size
+  limit, which could allow bandwidth amplification if an upstream returns very
+  large responses.
+
+---
+
+## Category 12: Upstream TLS Certificate Verification
+
+### 12.1 Upstream TLS Certificate
+
+**Source**: Network (upstream server's TLS certificate)
+**Entry**: `src/proxy/handler.rs:240-258` — `create_https_client()`
+**Input**: TLS certificate presented by the upstream service during HTTPS
+  proxy connections
+**Validation**: Standard WebPKI validation using system root certificates
+  (`rustls_native_certs::load_native_certs()` at `handler.rs:262`). No custom
+  certificate pinning or allowlisting.
+**Risk**: Low for the proxy itself. Risk is to the upstream connection: if
+  system root certs are compromised or missing, upstream connections could be
+  intercepted or fail.
+
+---
+
+## Priority Surfaces for Adversarial Analysis
+
+The following entry points are ranked by the combination of attacker control
+and logic impact — where untrusted input most directly influences a decision or
+construction:
+
+### P1. Request URI Path + Query → Upstream URL Construction
+
+**File**: `src/proxy/handler.rs:206-216` (`build_upstream_uri`)
+**Why**: Client-controlled path and query are concatenated verbatim into the
+upstream URL with no sanitization. This is the #1 spot for finding real
+vulnerabilities. Specific patterns to test:
+- Path traversal: `/../../../etc/passwd`
+- CRLF injection in query strings: `?x=%0d%0aInjected-Header:%20value`
+- Double-encoding: `/%252e%252e%252f`
+- Null bytes: `/%00`
+- Unicode normalization: `/Ｎ/` (fullwidth Latin) vs `/N/`
+- Path confusion between proxy and upstream: `/path/..%2f..%2fsecret`
+
+### P2. Host Header in HTTP→HTTPS Redirect
+
+**File**: `src/tls/redirect.rs:41-69`
+**Why**: Client-controlled Host header is interpolated into the Location response
+header. Classic header injection / open redirect vector. `HeaderValue::from_str()`
+is the primary defense but should be explicitly tested for CRLF bypass.
+
+### P3. All Client Headers Forwarded to Upstream
+
+**File**: `src/proxy/handler.rs:223-225`
+**Why**: Only hop-by-hop headers are stripped. All other headers pass through
+unchecked. Request smuggling conditions arise when the proxy and upstream
+disagree on header parsing. Specific patterns:
+- Duplicate `Content-Length` headers
+- `Transfer-Encoding: chunked` with HTTP/1.0
+- `Transfer-Encoding` obfuscation (e.g., `chunked, identity`)
+- `Content-Length` and `Transfer-Encoding` disagreement
+
+### P4. Config File Read on Reload
+
+**File**: `src/shutdown.rs:88`, `src/admin/socket.rs:257`
+**Why**: Config is re-read from disk on SIGHUP and admin reload. TOCTOU between
+read and use. If config is compromised (via a separate vulnerability or
+misconfiguration), the proxy will happily apply attacker-controlled upstream
+addresses, creating an effective SSRF.
+
+### P5. ACME Directory URL
+
+**File**: `src/tls/acme.rs:29-33`
+**Why**: Arbitrary URL from config used as ACME endpoint without format
+validation. If config is compromised, certificate requests go to an
+attacker-controlled server.
+
+---
+
+## Surfaces Where Rust's Memory Model Eliminates Entire Bug Classes
+
+These are patterns that would be high-priority in C/C++ but are automatically
+safe in Rust:
+
+- **Buffer overflows** in URI parsing, header parsing, body reading — hyper
+  and axum handle all buffer management safely
+- **Use-after-free** in connection handling — Rust's ownership model prevents
+  dangling references to connection state
+- **Integer overflow** in Content-Length parsing — `u64::parse` and `u32::parse`
+  are checked operations
+- **Null pointer dereference** in config access — `Option` and `Result` enforce
+  explicit handling
+- **Race conditions** in config reload — `ArcSwap` provides lock-free atomic
+  swaps; `Mutex` serializes concurrent reloads
+
+The remaining risk surface is **logic bugs in the glue** — incorrect
+construction, insufficient validation, or wrong assumptions about what the
+battle-tested components (hyper, rustls, tokio) guarantee.