Authors:
(1) Diwen Xue, University of Michigan;
(2) Reethika Ramesh, University of Michigan;
(3) Arham Jain, University of Michigan;
(4) Arham Jain, Merit Network, Inc.;
(5) J. Alex Halderman, University of Michigan;
(6) Jedidiah R. Crandall, Arizona State University/Breakpointing Bad;
(7) Roya Ensaf, University of Michigan. Table of Links Abstract and 1 Introduction 2 Background & Related Work 3 Challenges in Real-world VPN Detection 4 Adversary Model and Deployment 5 Ethics, Privacy, and Responsible Disclosure 6 Identifying Fingerprintable Features and 6.1 Opcode-based Fingerprinting 6.2 ACK-based Fingerprinting 6.3 Active Server Fingerprinting 6.4 Constructing Filters and Probers 7 Fine-tuning for Deployment and 7.1 ACK Fingerprint Thresholds 7.2 Choice of Observation Window N 7.3 Effects of Packet Loss 7.4 Server Churn for Asynchronous Probing 7.5 Probe UDP and Obfuscated OpenVPN Servers 8 Real-world Deployment Setup 9 Evaluation & Findings and 9.1 Results for control VPN flows 9.2 Results for all flows 10 Discussion and Mitigations 11 Conclusion 12 Acknowledgement and References Appendix 9 Evaluation & Findings We started the evaluation on August 13, 2021, and kept the monitor running for a week until August 20. Table 3 contains high-level statistics of the evaluation. A more detailed result that breaks down statistics by each control VPN configuration can be found in Appendix Table 5. 9.1 Results for control VPN flows Overall, we are able to identify 1,718 out of 2,000 vanilla flows, corresponding to 39 out of 40 unique configurations. This suggests the majority of OpenVPN traffic and servers are vulnerable to passive filtering and active probing, respectively. The few exceptions correspond to VPN providers that only offer UDP-based services or hide their servers behind IDS [7], which thwarts our probing attempts. Surprisingly, we also identify over two-thirds of all obfuscated flows, corresponding to 34 out of 41 obfuscated configurations. This result is mostly due to obfuscated services using OpenVPN as their backbone protocol and insufficient obfuscation failing to mask OpenVPN’s fingerprints. Alarmingly, out of the “top 10” VPN providers ranked by top10vpn.com [52], eight provide obfuscation services of some sort, suggesting that being undetectable is within the providers’ threat model for their clients. Yet, all of them are flagged as suspect flows due to either insufficient encryption (Opcode) or insufficient obfuscation over packet length (ACK). Considering that these obfuscated VPN services usually claim to be “undetectable” or claim that the obfuscation “keeps you out of trouble” [5, 54], this result is alarming as users who use these services may have a false sense of privacy and “unobservability”. 4 out of the “top 5” VPN providers use XOR-based obfuscation, which is easily fingerprintable. We find that among the “top 5” VPN providers [52], four offer obfuscated services, all of which nonetheless are flagged as OpenVPN flows by our Filter over 90% of the time. A closer look at the raw packet capture suggests that all of them employ obfuscations that are almost identical to the unofficial XOR patch, thereby making them vulnerable to fingerprinting. Alarmingly, the XOR-based obfuscation—despite being rejected by OpenVPN developers [57]—appears to be a major obfuscation strategy adopted by the majority of VPN providers we test, who often praise the patch for its simplicity and low overhead. Although the patch can bypass some of the most basic filters adopted by existing open-source DPI tools, we have demonstrated that even a slightly more sophisticated filter will be able to reliably and accurately detect them. Wrapping OpenVPN inside encrypted tunnels is a popular obfuscation strategy, yet some flows are still recognizable due to a lack of random padding. Another popular class of obfuscation strategies is tunnel-based, which wraps OpenVPN traffic inside an encrypted tunnel to frustrate any analysis over packet payloads. Examples include Stunnel, SSH tunnel, Shadowsocks, obfs{2/3/4}, and V2Ray(VMess). Overall, we find 20 obfuscated configurations deployed by 14 VPN providers that are tunnel-based. However, most of these tunnels do not add random padding to the payload being tunneled, with the only exceptions being obfs4 and VMess which can draw packet sizes from certain distributions. Among the 20 tunnel-based obfuscated services, only three of them deploy obfs4 and only one deploys VMess, leaving the remaining 16 vulnerable to ACK fingerprinting. We note that this does not mean these tunneling tools do not work, but rather that protection against traffic analysis is not among the design goals. For example, the threat model of obfs3, which is deployed by Perfect Privacy VPN, states that the obfuscator “does not try to protect against non-content protocol fingerprints, like the packet size or timing” [32]. Yet, we have demonstrated that for applications with distinct signature over packet length, such as OpenVPN, even the simplest thresholdbased detection can identify them with reasonable accuracy. UDP and obfuscated servers often share infrastructure with vanilla TCP servers, leaving them “guilty by association”. We discover that the majority of UDP and obfuscated OpenVPN services are co-located with vanilla TCP servers. For example, TorGuard hosts vanilla and stunnelobfuscated OpenVPN instances on the same host but different ports, whereas Perfect Privacy hosts them in neighboring IPs (*.*.193.26 for vanilla, *.*.193.27 for Stunnel, *.*.193.28 for SSH, and *.*.193.29 for obfs3). We find that for 34 out of 41 obfuscated services, at least one vanilla OpenVPN TCP server can be found within the server’s /29 subnet. Similarly, we were able to actively probe 18 out of 20 UDP configurations due to their co-location with TCP servers. In addition, we also find five providers sharing infrastructures used by their obfuscated services. For example, one IP (23.95.*.*) hosts Cryptostorm’s SSH-obfuscated service as well as SecureVPN’s vanilla servers. This result is only a lower bound as we did not connect to every single server available from each provider. Obfuscated services using shared infrastructures may be easier for adversaries to identify and block. On the positive side, some deployed services successfully evade our detection. Some providers deploy randomizers such as obfs4, v2ray, or proprietary protocols with random padding, which stopped us at the filtering stage (e.g. Tunnelbear). In addition, some providers deploy their obfuscated servers behind a firewall or IDS, which would respond with SYN-ACKs to every arriving SYN packet on almost all TCP ports [13,21]. Since we limit probe targets to 2,000 open ports per IP for practical considerations, this leads to false negatives when none of the probes hit an OpenVPN-listening port. Moreover, some VPN providers do not host vanilla OpenVPN TCP servers at all, such as VyprVPN, which currently only supports UDP as transport. For these providers, even though our Filter flags their flows as suspected OpenVPN, we were not able to confirm with subsequent probing. Finally, some providers host UDP or obfuscated servers outside the /29 probing range of the vanilla TCP ones, and we miss them due to probing resource constraints. This paper is available on arxiv under CC BY 4.0 DEED license. Authors: (1) Diwen Xue, University of Michigan; (2) Reethika Ramesh, University of Michigan; (3) Arham Jain, University of Michigan; (4) Arham Jain, Merit Network, Inc.; (5) J. Alex Halderman, University of Michigan; (6) Jedidiah R. Crandall, Arizona State University/Breakpointing Bad; (7) Roya Ensaf, University of Michigan. Authors: Authors: (1) Diwen Xue, University of Michigan; (2) Reethika Ramesh, University of Michigan; (3) Arham Jain, University of Michigan; (4) Arham Jain, Merit Network, Inc.; (5) J. Alex Halderman, University of Michigan; (6) Jedidiah R. Crandall, Arizona State University/Breakpointing Bad; (7) Roya Ensaf, University of Michigan. Table of Links Abstract and 1 Introduction Abstract and 1 Introduction 2 Background & Related Work 2 Background & Related Work 3 Challenges in Real-world VPN Detection 3 Challenges in Real-world VPN Detection 4 Adversary Model and Deployment 4 Adversary Model and Deployment 5 Ethics, Privacy, and Responsible Disclosure 5 Ethics, Privacy, and Responsible Disclosure 6 Identifying Fingerprintable Features and 6.1 Opcode-based Fingerprinting 6 Identifying Fingerprintable Features and 6.1 Opcode-based Fingerprinting 6.2 ACK-based Fingerprinting 6.2 ACK-based Fingerprinting 6.3 Active Server Fingerprinting 6.3 Active Server Fingerprinting 6.4 Constructing Filters and Probers 6.4 Constructing Filters and Probers 7 Fine-tuning for Deployment and 7.1 ACK Fingerprint Thresholds 7 Fine-tuning for Deployment and 7.1 ACK Fingerprint Thresholds 7.2 Choice of Observation Window N 7.2 Choice of Observation Window N 7.3 Effects of Packet Loss 7.3 Effects of Packet Loss 7.4 Server Churn for Asynchronous Probing 7.4 Server Churn for Asynchronous Probing 7.5 Probe UDP and Obfuscated OpenVPN Servers 7.5 Probe UDP and Obfuscated OpenVPN Servers 8 Real-world Deployment Setup 8 Real-world Deployment Setup 9 Evaluation & Findings and 9.1 Results for control VPN flows 9 Evaluation & Findings and 9.1 Results for control VPN flows 9.2 Results for all flows 9.2 Results for all flows 10 Discussion and Mitigations 10 Discussion and Mitigations 11 Conclusion 11 Conclusion 12 Acknowledgement and References 12 Acknowledgement and References Appendix Appendix 9 Evaluation & Findings We started the evaluation on August 13, 2021, and kept the monitor running for a week until August 20. Table 3 contains high-level statistics of the evaluation. A more detailed result that breaks down statistics by each control VPN configuration can be found in Appendix Table 5. 9.1 Results for control VPN flows control Overall, we are able to identify 1,718 out of 2,000 vanilla flows, corresponding to 39 out of 40 unique configurations. This suggests the majority of OpenVPN traffic and servers are vulnerable to passive filtering and active probing, respectively. The few exceptions correspond to VPN providers that only offer UDP-based services or hide their servers behind IDS [7], which thwarts our probing attempts. Surprisingly, we also identify over two-thirds of all obfuscated flows, corresponding to 34 out of 41 obfuscated configurations. This result is mostly due to obfuscated services using OpenVPN as their backbone protocol and insufficient obfuscation failing to mask OpenVPN’s fingerprints. Alarmingly, out of the “top 10” VPN providers ranked by top10vpn.com [52], eight provide obfuscation services of some sort, suggesting that being undetectable is within the providers’ threat model for their clients. Yet, all of them are flagged as suspect flows due to either insufficient encryption (Opcode) or insufficient obfuscation over packet length (ACK). Considering that these obfuscated VPN services usually claim to be “undetectable” or claim that the obfuscation “keeps you out of trouble” [5, 54], this result is alarming as users who use these services may have a false sense of privacy and “unobservability”. 4 out of the “top 5” VPN providers use XOR-based obfuscation, which is easily fingerprintable. We find that among the “top 5” VPN providers [52], four offer obfuscated services, all of which nonetheless are flagged as OpenVPN flows by our Filter over 90% of the time. A closer look at the raw packet capture suggests that all of them employ obfuscations that are almost identical to the unofficial XOR patch, thereby making them vulnerable to fingerprinting. Alarmingly, the XOR-based obfuscation—despite being rejected by OpenVPN developers [57]—appears to be a major obfuscation strategy adopted by the majority of VPN providers we test, who often praise the patch for its simplicity and low overhead. Although the patch can bypass some of the most basic filters adopted by existing open-source DPI tools, we have demonstrated that even a slightly more sophisticated filter will be able to reliably and accurately detect them. 4 out of the “top 5” VPN providers use XOR-based obfuscation, which is easily fingerprintable. Wrapping OpenVPN inside encrypted tunnels is a popular obfuscation strategy, yet some flows are still recognizable due to a lack of random padding. Another popular class of obfuscation strategies is tunnel-based, which wraps OpenVPN traffic inside an encrypted tunnel to frustrate any analysis over packet payloads. Examples include Stunnel, SSH tunnel, Shadowsocks, obfs{2/3/4}, and V2Ray(VMess). Overall, we find 20 obfuscated configurations deployed by 14 VPN providers that are tunnel-based. However, most of these tunnels do not add random padding to the payload being tunneled, with the only exceptions being obfs4 and VMess which can draw packet sizes from certain distributions. Among the 20 tunnel-based obfuscated services, only three of them deploy obfs4 and only one deploys VMess, leaving the remaining 16 vulnerable to ACK fingerprinting. We note that this does not mean these tunneling tools do not work, but rather that protection against traffic analysis is not among the design goals. For example, the threat model of obfs3, which is deployed by Perfect Privacy VPN, states that the obfuscator “does not try to protect against non-content protocol fingerprints, like the packet size or timing” [32]. Yet, we have demonstrated that for applications with distinct signature over packet length, such as OpenVPN, even the simplest thresholdbased detection can identify them with reasonable accuracy. Wrapping OpenVPN inside encrypted tunnels is a popular obfuscation strategy, yet some flows are still recognizable due to a lack of random padding. UDP and obfuscated servers often share infrastructure with vanilla TCP servers, leaving them “guilty by association”. We discover that the majority of UDP and obfuscated OpenVPN services are co-located with vanilla TCP servers. For example, TorGuard hosts vanilla and stunnelobfuscated OpenVPN instances on the same host but different ports, whereas Perfect Privacy hosts them in neighboring IPs (*.*.193.26 for vanilla, *.*.193.27 for Stunnel, *.*.193.28 for SSH, and *.*.193.29 for obfs3). We find that for 34 out of 41 obfuscated services, at least one vanilla OpenVPN TCP server can be found within the server’s /29 subnet. Similarly, we were able to actively probe 18 out of 20 UDP configurations due to their co-location with TCP servers. In addition, we also find five providers sharing infrastructures used by their obfuscated services. For example, one IP (23.95.*.*) hosts Cryptostorm’s SSH-obfuscated service as well as SecureVPN’s vanilla servers. This result is only a lower bound as we did not connect to every single server available from each provider. Obfuscated services using shared infrastructures may be easier for adversaries to identify and block. UDP and obfuscated servers often share infrastructure with vanilla TCP servers, leaving them “guilty by association”. On the positive side, some deployed services successfully evade our detection. Some providers deploy randomizers such as obfs4, v2ray, or proprietary protocols with random padding, which stopped us at the filtering stage (e.g. Tunnelbear). In addition, some providers deploy their obfuscated servers behind a firewall or IDS, which would respond with SYN-ACKs to every arriving SYN packet on almost all TCP ports [13,21]. Since we limit probe targets to 2,000 open ports per IP for practical considerations, this leads to false negatives when none of the probes hit an OpenVPN-listening port. Moreover, some VPN providers do not host vanilla OpenVPN TCP servers at all, such as VyprVPN, which currently only supports UDP as transport. For these providers, even though our Filter flags their flows as suspected OpenVPN, we were not able to confirm with subsequent probing. Finally, some providers host UDP or obfuscated servers outside the /29 probing range of the vanilla TCP ones, and we miss them due to probing resource constraints. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Study Flags OpenVPN Flows with High Accuracy and Minimal False Positives

OpenVPN is Open to VPN Fingerprinting: Real-world Deployment Setup

VirtualMachine.Tech

Too Long; Didn't Read

Make resilience your competitive advantage

OpenVPN Obfuscation Flaws: Study Uncovers Detection Vulnerabilities

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

OpenVPN is Open to VPN Fingerprinting: Appendix

Windows Sticky Keys Exploit: The War Veteran That Never Dies

06/02/2018: Biggest Stories in the Cryptosphere

0-Days are on the Rise and that Means a Lot More Work for SOC Teams

Time Bombs Inside Software: 0-Day Log4Shell is Just the Tip of The Iceberg

OpenVPN is Open to VPN Fingerprinting: Appendix

Windows Sticky Keys Exploit: The War Veteran That Never Dies

06/02/2018: Biggest Stories in the Cryptosphere

0-Days are on the Rise and that Means a Lot More Work for SOC Teams

Time Bombs Inside Software: 0-Day Log4Shell is Just the Tip of The Iceberg

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps