obfs4 Protocol Technical Deep Dive

obfs4's handshake uses Diffie-Hellman key exchange with Curve25519 elliptic curve cryptography. The server's long-term Curve25519 public key is encoded in the bridge descriptor string that clients receive. During connection establishment, both client and server generate ephemeral Curve25519 keypairs. The client encrypts a nonce with the server's long-term public key using NaCl's crypto_box, combined with the client's ephemeral public key and a timestamp. This handshake prevents passive observers from distinguishing obfs4 connections from random encrypted data because the handshake does not begin with any fixed byte pattern. Active probing attacks (where a censor tries to connect to a suspected obfs4 bridge to identify it) are defeated because without the server's long-term public key (from the bridge descriptor), a prober cannot complete a valid handshake.

After handshake, obfs4 wraps Tor protocol data in frames that are encrypted and formatted to appear as random byte streams. obfs4 uses a length-masking technique: it inserts random padding to normalize packet lengths, preventing traffic fingerprinting based on characteristic Tor packet sizes. The frame format uses ChaCha20-Poly1305 AEAD encryption, providing both confidentiality and integrity. Importantly, obfs4 does NOT perform inter-packet timing obfuscation (adding delays between packets) - it only obfuscates packet content and partially normalizes lengths. This means sophisticated timing analysis comparing packet inter-arrival times could potentially distinguish obfs4 streams from background HTTPS traffic, though this attack requires significant monitoring capability and is not deployed by most censors.

obfs4 provides three inter-arrival time (IAT) modes configurable in the bridge descriptor: iat-mode=0 disables IAT shaping (fastest, default for most bridges), iat-mode=1 enables obfuscation at the Tor protocol layer (moderate timing obfuscation with some overhead), and iat-mode=2 provides more aggressive timing obfuscation at higher performance cost. For high-censorship environments where deep packet inspection includes timing analysis (rare but present in some national systems), iat-mode=1 or iat-mode=2 provides stronger obfuscation. Bridge operators configure iat-mode in the ServerTransportPlugin configuration: ServerTransportOptions obfs4 iat-mode=1. Users connecting to the bridge use the iat-mode specified in the bridge descriptor they receive.

Install Tor and the obfs4proxy binary (apt install tor obfs4proxy on Debian/Ubuntu). Configure /etc/tor/torrc with: ORPort 443, ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy, ServerTransportListenAddr obfs4 0.0.0.0:9443, BridgeRelay 1, PublishServerDescriptor bridge. Run systemctl start tor and retrieve your bridge's descriptor from the notice log: grep 'Registered server transport' /var/log/tor/notices.log. The output contains your bridge's obfs4 descriptor in the format: Bridge obfs4 IP:PORT FINGERPRINT cert=BASE64 iat-mode=0. For performance, ensure the server has sufficient file descriptor limits and a low-latency network connection. obfs4 proxy is CPU-efficient and handles thousands of simultaneous connections on modest hardware.

Running an obfs4 bridge exposes your server's IP and port to all users who receive your bridge descriptor from the Tor Project's BridgeDB distribution system. While the obfs4 protocol prevents casual identification of connections, your IP is known to the users who connect to you. This is acceptable for most operators but means your server IP should not be shared with sensitive services on the same host. Bridge operators in certain jurisdictions may face legal scrutiny similar to relay operators - understand your local legal context. Consider using a dedicated VPS for bridge operation rather than your primary server. Update obfs4proxy regularly as security vulnerabilities are addressed in releases. Monitor bridge connection counts via the control port to detect unusual traffic patterns that might indicate abuse.