1 of 28

VPN or Vpwn? How Afraid Should You Be of VPN Traffic Identification?

An Empirical Analysis of VPN Traffic Fingerprinting in the Age of Censorship

​

Tanmay Rajore, Jithin S, Arnav Gupta, Keshav Gambhir, Anindya Prithvi, Dr. Sambuddho Chakravarty

IIIT Delhi�

Network Traffic Measurement and Analysis (TMA 2025)

1

2 of 28

VPN

2

Ideal Pathway

Image credit: sunteco

Protocols (in use today)

Older protocols (insecure/deprecated)

TLS

3 of 28

VPN Tunneling

3

Image credit: palo-alto-networks[link]

4 of 28

VPN Identification

  • VPN Identification
    • Process of detecting VPN traffic without decrypting it
    • Relies on identifying protocol patterns (headers, handshakes, traffic behavior
    • Used by ISPs and censors for blocking or surveillance
  • Xue et al. (Usenix’2022) – “OpenVPN is open to fingerprinting”
    • OpenVPN: leaks control opcodes, easily fingerprinted

​

  • Frolov and Wustrow (2019) – "The Use of TLS in Censorship Circumvention“
    • reveal SNI or cipher suite anomalies

4

5 of 28

Why This Matters

  • Governments banning/monitoring VPNs
  • Examples: China, Iran, India 2022, Russia
  • Core question: Can VPN traffic be reliably identified using middleboxes and firewalls?

5

Links – [1][2][3]

6 of 28

Research Questions

  • Can adversaries identify VPN traffic using DPI based middleboxes?
    • Based on current capabilities based on Datasheets and manual
    • Ex.- Fortinet OS/hardware offerings, Bluecoat Packetshaper series

​

  • Which protocols are most/least vulnerable?
    • Most – easily identifiable ( repeated patterns, plaintext identifiers)
    • Least – hard to detect using Firewalls and Middlesboxes current capabilities

​

  • What evasion strategies actually work?
    • Practical solutions and usability

6

7 of 28

Threat Model

  • ISP-level adversary firewalls/middleboxes

​

  • DPI-enabled middleboxes – cannot parse at arbitrary offsets in real time.

​

  • Can’t do large-scale ML on the middlebox or firewall at line rate.

​

7

8 of 28

Methodology Overview

  • Choice VPNs
    • protocol diversity along with popularity
  • Traffic Examination
    • Tools – MITMProxy, Wireshark
    • Kernel netfilter modules
  • Markers we looked for?
    • SNI and plaintext identifiers
    • Packet size patterns
    • protocol signatures( opcodes )
    • Open ports and service providers
    • Application Reverse Engineering - flow of information
  • Platforms: Windows, Android, Linux, MacOS

8

Logo rights belong to respective company , link1

9 of 28

Protocol Taxonomy

9

Open-Source VPNs

Proprietary VPNs

Freely available software with�modifiable code and�configurations.

​

Ex- OpenVPN, Wireguard

Vendor-specific extensions with�custom features and undocumented�protocols.

​

Ex- Lightway, Nordlynx, Chameleon

10 of 28

Commercial VPN connection

10

2 Step Process – client application ( after login using username /password)

​

1. Authentication with Authentication server to fetch the VPN gateway details. (API calls)

    • Hosted by Major cloud provider

​

2. Connection to the VPN gateway

    • Using the data received from the auth server, the client application connects to specified gateways.

​

Authentication Server

Weakness: An Adversary can just block the Authentication step

11 of 28

OpenVPN

11

Vanilla – OpenVPN

    • Encapsulation
    • Handshake flow
    • Opcodes

12 of 28

OpenVPN

  • Both the implementations of OpenVPN
    • Vanilla and commercial
      • opcodes including XOR patch (plaintext) [usenix’22]
      • XOR patch leaves 1 byte of opcode ( XOR patch algorithm) [usenix’22] – harder for firewalls
  • Malformed Packets – sending malformed HMAC packets get ignored by server
  • Pre-shared Key mode
    • Complete packet is encrypted
    • Not Scalable
  • New Protocol Proposal [towards the end]
    • Benefits of PSK + Scalable

12

13 of 28

Wireguard

  • Next-Gen protocol, Lightweight, UDP based
  • the user’s identity must be stored on the server and linked to an internal IP address assigned by the VPN

​

  • Weakness
    • Plaintext identifiers
    • Fixed offset of repeated identifiers

​

​

13

14 of 28

Wireguard

  • Commercial implementations provide only user level anonymization
  • double NAT system allows NordLynx connection without storing any identifiable data on a server.
  • Base Protocol – same (No protection from Identification at protocol level)

14

Image credits: [Link]

15 of 28

TLS and SSH-based VPNs

  • TLS 1.3
    • Protocol for securing web and VPN traffic
    • Faster, more secure than TLS 1.2 (1-RTT handshake)
    • Potential Markers:
      • SNI (Server Name Indication): still sent in plaintext (used for VPN detection)
      • Number of Cipher Suites
      • Certificates encrypted: prevents domain exposure post-handshake
    • Used in TLS-based VPNs (e.g., ProtonVPN Stealth, ExpressVPN Lightway)

15

Image credits: [link]

16 of 28

TLS and SSH-based VPNs

  • SSH (Secure Shell)
    • Secure channel for remote access and tunneling
    • Authenticates using keys or passwords
    • Encrypts all traffic, including handshakes
    • Potential Markers:
      • Port 22 – default but can change
      • SSH protocol version banner (e.g., SSH-2.0-OpenSSH_8.2) during handshake
      • Packet size & timing patterns: regular keepalives, interactive keystrokes
    • Used in VPN obfuscation (e.g., OpenVPN over SSH)
    • Harder to distinguish from regular SSH traffic

16

Image credits: [link]

17 of 28

TLS and SSH-based VPNs

  • measures used by popular implementations
    • Obfuscation via TLSv1.3
    • Randomized SNI fields (ex- ‘bdcyw.tr’,’ofd.es’)
    • No SNI (rare, detectable) [NDSS’19]
    • ProtonVPN Stealth, ExpressVPN Lightway ( mimic Browser TLS)��Browser TLS requests – not using only single cipher, legible SNI, ports

​

17

18 of 28

TLS and SSH-based VPNs

  • SSH based observations
    • VyprVPN - Chameleon [SSH tunnelled OVPN]
    • Identical to SSH tunnel traffic [general SSH handshake markers]
    • Ciphers and handshake is SSH equivalent to standards
    • High collateral damage if blocked without analysis.

​

18

19 of 28

Evasion Techniques

  • SNI poisoning
    • Change the SNI field to non-blocked Domains
      • Worked on Akami, fastly, Azure, Amazon hosted domains
      • Cloudflare – blocked – due to Cloudflare routing requirement for SNI matching with hostname check.

​

19

  • MTU manipulation
    • Reducing the MTU from standard 1500 bytes to lower values in the range of 500.
    • Packet fragmentation
    • Evaded detection by Firewalls and Middleboxes without MITM
    • Minimal performance Hit for text based traffic.

20 of 28

Performance Results

  • CDF graphs for MTU 500 vs 1500
  • Tranco List top 1K
  • Across open-source Protocols
    • OpenVPN TCP
    • OpenVPN UDP
    • Wireguard

​

​

20

21 of 28

Firewalls

  • Modern Firewalls - Static signatures [ Fortinet, checkpoint, Bluecoat]
  • Limited Configurability – specific fields
  • Software based ML- solutions coming up

​

Firewall tested : Fortinet 2601F ( FortiOS 7.6)

    • Blocked vanilla OpenVPN
    • XOR patch – bypassed the filter
      • (Not able to detected the dynamic change)

21

22 of 28

Firewalls

22

Fortinet Labs signature update [link], Juniper [link]

Static signatures try to keep up with the protocol changes

23 of 28

Firwalls

  • Configurability
    • Limited to specific fields and fixed patterns
    • No dynamic Nature for detection for custom definitions
    • Ex- Fortinet custom rules

​

23

24 of 28

VPN Detection Table

  • Non-identifiable – No identifiable characteristics
  • partially-identifiable – i.e., only 1 packet contains identifiable information
  • Identifiable -identifiable under certain conditions
  • Easily Identifiable –fixed across multiple packets

24

25 of 28

Limitations

  • Broader selection of VPN providers
  • lack of access to ISP infrastructure - Inference based only on Wireshark captures and firewall hardware documentation
  • Endpoint enumeration - Endpoint discovery was conducted via periodic cloud-based connections to VPN endpoints ( spl. Public API requests)
  • Cloudflare strictness - no SNI based evasion.
  • Updates to application features - Findings are based on tested VPN versions and configurations; future updates may impact performance and detectability.

​

25

26 of 28

Our Proposed Fix

  • Modification to OVPN pre-shared key mode
  • Encryption of Complete packet payload
  • Incorporating techniques for Authentication steps

26

27 of 28

Conclusion

  • Increasing Censorship : Countries monitoring and banning VPNs to limit access to blocked content.
  • OpenVPN is vulnerable: Prior research confirms OpenVPN flows and endpoints are detectable with specific configurations.
  • Alternative protocols offer resilience: TLS, SSH, and IPSec are harder to detect and block without causing collateral damage.
  • Evasion through MTU manipulation: Reducing MTU to fragment identifiable patterns across packets shows promise with minimal performance impact.
  • Future work: Further research is needed to refine evasion strategies and assess long-term effectiveness against adaptive censors.

​

​

27

28 of 28

References

  • [1] OpenVPN is Open to VPN Fingerprinting – Usenix’22 [link]
  • [2] The Use of TLS in Censorship Circumvention – NDSS’19 [link]
  • [3] Fortinet [link]
  • [4] Juniper Firewalls Application Control [link]
  • [5] TLS and SSH RFC [ link1, link2]

​

28