permissionlesstech/bitchat
1
0
Fork 0
mirror of https://github.com/permissionlesstech/bitchat.git synced 2026-07-25 22:25:20 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fail closed on unverified egress and gate the already-ready connect path

Browse Source 
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>
This commit is contained in:
jack
2026-07-01 23:57:29 +02:00
co-authored by Claude Fable 5
parent c7ee2a4cb4
commit ad5fb1ddc6
6 changed files with 335 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files
localPackages/Arti/Sources/TorManager.swift
+13 -3
View File
@@ -133,11 +133,21 @@ public final class TorManager: ObservableObject {
return await MainActor.run(body: { self.networkPermitted })
}
/// Synchronous, cached view of the egress gate: `true` while a positive
/// egress verification is within its TTL (or when Tor is not enforced).
/// When this is `false`, callers must route through `awaitEgressReady()`
/// (which probes) before opening any connection — never connect directly.
public var isEgressVerified: Bool {
guard torEnforced else { return true }
return egressVerifier.hasFreshVerification
}
/// Like `awaitReady`, but additionally requires that a canary request
/// through the proxied session positively verifies Tor egress. Returns
/// `false` if Tor never became ready, or if the egress self-check
/// positively detected a non-Tor (direct) egress. Callers must fail closed
/// on `false` — never fall back to a direct connection.
/// `false` if Tor never became ready, or if the egress self-check could
/// not positively verify a Tor exit (non-Tor egress detected, or canary
/// unreachable → unverified). Callers must fail closed on `false` — never
/// fall back to a direct connection.
nonisolated
public func awaitEgressReady(timeout: TimeInterval = 75.0) async -> Bool {
let ready = await awaitReady(timeout: timeout)