2022-xue-openvpn
findings extracted from this paper
-
OpenVPN's application-layer P_ACK packets — uniform in size and concentrated only in the handshake phase — provide a timing and count fingerprint detectable via threshold comparison over 10-packet bins. Tunnel-based obfuscation wrappers (Stunnel, SSH, obfs2/3, Shadowsocks) that do not add random padding preserve the 1:1 packet correspondence with the underlying OpenVPN stream, leaving 16 of 20 tested tunnel-based obfuscated configurations vulnerable to ACK fingerprinting.
-
34 of 41 obfuscated OpenVPN configurations and 18 of 20 UDP configurations were co-located with vanilla TCP OpenVPN servers within the same /29 subnet; probing the /29 subnet of a suspected obfuscated or UDP endpoint revealed nearby vanilla TCP servers, enabling confirmation by 'guilt by association' even when the obfuscated endpoint itself resisted direct fingerprinting. Some providers additionally share infrastructure across different VPN brands, further compounding exposure.
-
A two-phase passive-filter-plus-active-probing framework deployed at a 1-million-user ISP identified 85.90% of vanilla OpenVPN flows (1,718/2,000) and 72.67% of obfuscated flows (1,468/2,020), with an upper-bound false positive rate of 0.0039% across over 10 million flows — three orders of magnitude lower than prior ML-based approaches (1.4–5.5%). The system processed 15 TB and 2 billion flows per day on a single commodity server.
-
Even with tls-auth/tls-crypt HMAC protection making OpenVPN servers nominally 'probe-resistant' (silent to unauthenticated clients), the framework fingerprints servers via TCP-level timing side channels: a complete 16-byte client-reset probe triggers an immediate connection drop (HMAC validation fails after full packet reassembly), while a 15-byte truncated probe causes the server to stall awaiting the final byte until a server-specific handshake timeout expires. Over 97% of non-OpenVPN endpoints have RST thresholds below 500 or above 4,000 bytes, versus OpenVPN's characteristic 1,550–1,660 bytes derived from default MTU configurations.
-
OpenVPN's unencrypted opcode header byte is exploited to fingerprint vanilla and XOR-obfuscated flows: the XOR patch specification excludes the first buffer byte (the opcode) from reversal, so opcodes are always XOR-ed with the same key byte and map deterministically to fixed ciphertext values. All 4 of the top-5 VPN providers that offer obfuscated services use XOR-based obfuscation, and all were flagged by opcode fingerprinting over 90% of the time.