Address two review findings on the Tor egress self-check:
1. Bypass on the already-bootstrapped path: shouldWaitForTorBeforeConnecting
only checked torIsReady, so once Tor was up, connectToRelays/connectToRelay
(initial connect, reconnect backoff timers, manual retry, subscription-
triggered connects) opened relay WebSockets without ever running the egress
canary. The gate now also requires a fresh cached egress verification
(TorManager.isEgressVerified, backed by a nonisolated TTL snapshot on
TorEgressVerifier); any path lacking one queues behind awaitEgressReady().
2. unreachable canary no longer allows: an unreachable canary is exactly the
ambiguous case where we cannot tell whether the platform honored the SOCKS
proxy, so it now refuses relay connections (fail-closed) instead of
allow-with-warning. A verifiedTor verdict still allows connection opens for
its 300s TTL (a cached good verdict covers brief canary blips); after TTL
expiry or invalidate() (Tor restart/dormant/shutdown) connections stay
closed until a probe succeeds again. Probe cadence stays bounded via the
verifier's minRetryInterval, and the relay manager schedules a bounded
30s-cadence gate retry after wait-attempt exhaustion so a transient canary
outage recovers automatically (GeoRelayDirectory already retries with its
own backoff).
Tests: verifier policy (unreachable refuses, recovery via retry, cached-
within-TTL allows during blip, TTL expiry + unreachable refuses, snapshot
invalidation) and relay-manager gating (ready path awaits egress verification,
reconnect requeues behind the gate, exhaustion schedules the bounded retry and
recovers).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Runtime-verified whether Apple's URLSession honors connectionProxyDictionary
SOCKS settings for Nostr relay traffic (plain HTTPS + URLSessionWebSocketTask),
since the app routes all Nostr traffic through Arti's local SOCKS5 proxy solely
via those keys and Apple does not officially support SOCKS for URLSession on iOS.
Verification harness (scripts/tor-egress-verification/): a minimal SOCKS5 CONNECT
proxy that logs arriving connections, plus a Swift probe that runs an HTTPS GET
and a WebSocket ping through a URLSession configured with the proxy dict. Result:
on macOS (kCFNetworkProxiesSOCKS* constants) and the iOS simulator (raw
"SOCKSProxy"/"SOCKSPort" string keys, the exact app path) BOTH HTTP and WebSocket
are proxied, do remote DNS through the proxy, and the proxied session is
fail-closed (every request errors when the SOCKS proxy is down). The feared
direct-egress leak did not reproduce on the tested platforms.
Defense-in-depth for the platform Apple does not guarantee (physical iOS):
add TorEgressVerifier, which performs a canary request through the proxied
session and asserts the exit is a Tor node (check.torproject.org IsTor==true),
positively detecting a direct egress even if the OS silently ignored the proxy.
Policy: verifiedTor allows (cached for a TTL); notTor refuses (leak detected,
never open relays); unreachable allows-with-warning (session stays fail-closed
by construction). Wired into TorManager.awaitEgressReady() and required by both
NostrRelayManager and GeoRelayDirectory before opening connections. Cache is
invalidated on Tor restart/dormant/shutdown. Never falls back to a direct
connection.
Probe is injected so the policy/caching is unit-tested offline; the live-network
harness lives under scripts/ and is not run by CI.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
