The final publication is available at IEEE via https://doi.org/10.1109/ICC42927.2021.9500375 Analysing Leakage during VPN Establishment in Public Wi-Fi Networks

Christian Burkert, Johanna Ansohn McDougall, Hannes Federrath and Mathias Fischer Universität Hamburg {burkert,ansohn.mcdougall,federrath,mfischer}@informatik.uni-hamburg.de

Abstract—The use of public Wi-Fi networks can reveal popular third-party clients fall short in protecting user privacy sensitive data to both operators and bystanders. A VPN can during the establishment of VPN connections. To summarise, prevent this. However, a machine that initiates a connection we make the following contributions: to a VPN server might already leak sensitive data before the VPN tunnel is fully established. Furthermore, it might not be • We systematise the current state of system APIs for immediately possible to establish a VPN connection if the network VPNs. requires authentication via a captive portal, thus increasing the • We analyse OS mechanisms for captive portal detection. leakage potential. In this paper we examine both issues. For that, • We examine the behaviour and leakage of native and we analyse the behaviour of native and third-party VPN clients on various platforms, and introduce a new method called selective third-party VPN clients, including in captive networks. VPN bypassing to avoid captive portal deadlocks. • We introduce Selective VPN Bypassing, a concept of Index Terms—wi-fi, hotspot, vpn, privacy, captive portal gradual and selective network capability management to avoid leakage during captive network remediation and I.INTRODUCTION VPN connection establishment. Public Wi-Fis supply Internet connectivity on the go. How- The remainder of this paper is structured as follows: In ever, their usage comes with considerable privacy risks: A Sect. II, we provide background and terminology. Sect. III Wi-Fi operator can monitor all traffic, analyse the metadata presents related work. In Sect. IV, we define the requirements and, in case of unencrypted connections, even expose its users for a secure VPN establishment. Sect. V describes the status to nearby sniffers and attackers [1], [2]. VPNs are used to quo on VPN APIs. In Sect. VI, we analyse VPN clients and mitigate these dangers by applying an additional layer of en- APIs for violations of our security requirements. Sect. VII cryption. However, they can also give a false sense of security: proposes a design for a leak-free VPN establishment, before Leakage of traffic can already occur while a user attempts to Sect. VIII concludes the paper. connect to a VPN, and a captive portal might even force the II.BACKGROUNDAND TERMINOLOGY user to temporarily disable the VPN altogether, because—as we will show in this paper—many VPN clients interfere with In this section, we briefly describe key concepts of Wi- captive portal detection. After joining the network, running Fi communication, captive portals and VPNs, and introduce applications like mail or chat clients will themselves attempt additional terminology used throughout the paper. to connect to their servers. During the time the VPN is not yet A Public Wi-Fi or Hotspot is a 802.11 Wi-Fi network that is established, this might leak potentially sensitive information open to the public, i. e., accepts connections from any client. about a user’s habits, preferences, or work environment to the Unless explicitly stated, we assume public Wi-Fis to operate network. without encryption. To mitigate the potential dangers of surfing VPNs were originally designed to establish connectivity to in an unencrypted public Wi-Fi, users can decide to increase remote private networks and to access their remote services. their security by utilising a VPN. With respect to VPNs, we Nowadays, they are mostly used for privacy-friendly surfing: introduce the term VPN Bootstrapping: It describes the process They aim at masking the original source IP addresses with of blocking all traffic except that required to establish the VPN that of the VPN endpoint and thereby protecting their users, connection until the VPN tunnel is successfully established. e. g., from observation by Internet Service Providers (ISPs). While public Wi-Fis can often be used without special For that use case, it is crucial that all traffic is routed via the access rights, providers can present their customers with a VPN tunnel and nothing is leaked to the intermediate network Captive Portal (CP): A website that users are automatically besides the VPN connection itself. redirected to that contains terms of service and sometimes With this paper, we are the first to examine the issue of the necessity to input credentials. Until the terms of the secure VPN establishment in captive networks and present captive portal are fulfilled, access to the Internet is blocked. evidence that native VPN clients shipped with Windows, The process of signing-in and lifting the network block is remediation Captive Network macOS, iOS, Android, and Ubuntu/GNU Linux, as well as denoted as . We use the term (CN) to refer to hotspots containing a captive portal. CPs can be explicitly announced via a DHCP option or a Router IEEE ICC 2021. ©2021 IEEE. DOI 10.1109/ICC42927.2021.9500375 Advertisement (RA) extension, which informs the client of the URI needed to access the authentication page. While these R4: Blocking Fail State: Outbound traffic continues to be announcement options exist and have been standardised [3], blocked if a VPN tunnel cannot be successfully estab- they are not widely adopted in practice. Instead, platforms lished (e. g., if the VPN endpoint is unreachable). apply heuristics to detect captive networks: Upon successfully R5: No Tunnel Bypass: After successful VPN tunnel estab- connecting to a network, clients send out HTTP requests to lishment, no non-VPN traffic, such as previously started a predefined URL, expecting a predefined response, e. g., an TCP streams, bypass the tunnel. Instead, any preexisting HTTP status code 204. A CN instead replies with an HTTP connection is interrupted and reestablished through the redirect (e. g., status code 307), redirecting the user to the tunnel. Periodic requests to check the state of the captive CP [4]. Thereby, the OS assumes a CN and displays the CP. network are exempted. When attempting to use a VPN in a CN, a Captive Deadlock can occur: in it, the leak prevention of a VPN client blocks V. VPN API STATUS QUO the communication with the CP that is necessary to gain an In this section, we describe the current state of system APIs Internet uplink, and thereby indirectly also blocks the route to available for VPNs on major platforms according to developer the VPN endpoint. documentation. a) Apple macOS and iOS: As part of their network III.RELATED WORK extension framework, Apple offers an API for creating VPN The security and privacy of public Wi-Fis and VPN client apps that build on Apple’s system VPN functionality (Per- software has been extensively studied in the literature. [1], [2], sonal VPN [11]) or provide custom protocol implementations [5] examine risks caused by public Wi-Fi and captive portals, (Packet Tunnel Provider [12]). This API offers always-on and the reason why people use them nonetheless. [6] and [7] functionality (R1) via so called on-demand rules, which can analyse the VPN clients on mobile platforms. [6], [8] and [9] be configured to trigger, e. g., when a Wi-Fi connection is verify the security and privacy claims of commercial VPN established [13]. According to the documentation, such on- clients. Among other things, they discover severe leakage of demand connection rules block outgoing traffic until the VPN IPv6 and DNS traffic: Up to 84% of VPN apps don’t tunnel tunnel is established (R3). IPv6 [6], and around 60% of VPN apps use Google’s DNS b) Android: Developers can build VPN apps using the servers, while only about 10% use own DNS resolvers [6]. system API and the BIND_VPN_SERVICE permission. VPN However, regarding traffic leakage during VPN connection apps can run in, among others, always-on (R1) and per-app establishment, there is very little prior work and—to the best mode. Always-on VPN connections are kept alive uncondi- of our knowledge—we are the first to analyse VPN clients tionally by the system as long as the device is running and and their behaviour in captive networks. Karlsson et al. [10] Internet connectivity is available. Developers of VPN apps present a prototypical device that connects to public Wi-Fis, can specify lists of allowed and disallowed apps whose traffic opens up a VPN tunnel and then creates an encrypted Wi-Fi is to be tunnelled through the VPN. It is also possible to for the user to connect to, such that all traffic is routed through block all connections outside the VPN tunnel, which results the VPN tunnel on the intermediate device. This mitigates the in disallowed apps losing all network connection [14]. startup leakage issue by moving it from the user device to the c) Windows 10: Always-on functionality (R1) is built in intermediate device which presumably exposes less sensitive as an auto-trigger for VPN profiles.1 In general, VPN profiles traffic of its own. However, we argue that the requirement to can be provided by a VPN app2 or via a mobile device maintain an additional device is impractical to most users. management mechanism to remote-join clients to a domain3. IV. REQUIREMENTSFOR SECURE VPNBOOTSTRAPPING d) Ubuntu GNU/Linux: Since the landscape of GNU/Linux distributions is very diverse, we focused To ensure a secure and privacy-preserving establishment of our analysis on the popular desktop distribution Ubuntu. VPN connections in public Wi-Fis, we propose the following Ubuntu uses NetworkManager (NM) as its high-level daemon requirements for secure VPN bootstrapping: for networking including VPN. NM provides APIs to plug R1: Always-on Functionality: A client offers an always-on in VPN services via DBus4 and libnm5. VPN services can or similar functionality that asserts that a VPN tunnel declare themselves persistent, i. e., they will attempt to is established when network connectivity is available. maintain the connection across link changes and outages.6 If not automated, the user must be able to activate VPNs can be further set as so-called secondaries for other this functionality without an existing Internet connection, e. g., before joining a public Wi-Fi. 1https://docs.microsoft.com/en-us/windows/security/identity-protection/ R2: Captive Network Support: The VPN client allows the OS vpn/vpn-auto-trigger-profile 2https://docs.microsoft.com/en-us/uwp/api/windows.networking.vpn. to perform captive portal detection and remediation or ivpnprofile?view=winrt-19041 performs it itself. The client does not cause a captive 3https://docs.microsoft.com/en-us/windows-server/remote/remote- deadlock. access/vpn/always-on-vpn/deploy/always-on-vpn-deploy 4https://developer.gnome.org/NetworkManager/stable/gdbus-org. R3: Minimal startup traffic: No traffic is sent from the client freedesktop.NetworkManager.VPN.Plugin.html device that is not necessary to remediate a captive net- 5https://developer.gnome.org/libnm/stable/NMVpnServicePlugin.html work or to establish a VPN tunnel. 6https://developer.gnome.org/libnm/stable/NMSettingVpn.html connections to be activated in reaction to the other connection TABLE I going online (R1). OVERVIEW OF PLATFORM BEHAVIOUR DURING CAPTIVE NETWORK REMEDIATION.

VI.EXPERIMENTAL ANALYSIS While the existing VPN APIs partially contain mechanisms macOSiOS WindowsAndroidUbuntu System employs CPD      to fulfil the requirements R1 and R3, apps using the API don’t Blocking of platform traffic      necessarily utilise the functionality or fail to fulfil the other Blocking of third-party traffic      requirements. In this section, we present an experimental anal- ysis concerning OS-specific Captive Portal Detection (CPD) mechanisms, and then test different VPN clients with respect B. Captive Portal Detection Mechanisms to their fulfilment of the requirements. To establish a baseline, we analysed each platform’s be- haviour when confronted with a captive network. These tests A. Testbed Setup and General Procedure were conducted without any VPN enabled. We analysed two 1) Setup: Our testbed comprises a Raspberry Pi that scenarios: a) CP sign-in is completed, i. e., the continue button runs the Wi-Fi Access Point (AP) and also captures the on the CP website is clicked, and b) CP sign-in is omitted, incoming Wi-Fi traffic of our test clients. We use a Rasp- leaving the client captured. We observed that all platforms berry Pi 3 Model B+ running Raspbian GNU/Linux 10 and employ effective Captive Portal Detection (CPD) mechanisms with hostapd 2.2.7 providing the WPA2-secured AP and and prompt the user to sign in to the captive network. How- Nodogsplash 4.5.1 beta providing the captive portal function- ever, the platforms exhibit the following differing behaviour ality. The captive network is set up to redirect (status code 307) regarding leakage during CPD, which is also summarised in plain HTTP requests to the captive portal sign-in page running Table I: On macOS and iOS, we find that CPD takes place on the same Raspberry Pi, where the user can gain Internet before connectivity is available to the rest of the system. If access by clicking a continue button. The traffic capturing is the sign-in is omitted, macOS and iOS will continue to block done with Wireshark/tshark. all other outgoing traffic. However on iOS, DNS queries were Regarding the test clients, we used the following setup: leaked about non-CPD-related platform hostnames, followed A Google Nexus 5X running Android 10.07, an iPad run- by IP traffic to those hosts. On Android, DNS lookups as ning iOS 13.7, a MacBook Pro running macOS 10.15.7, well as TCP traffic to non-CPD Google hosts take place be- Ubuntu 20.04 LTS with NetworkManager 1.22.10, and Win- fore remediation. On Ubuntu, the CPD appears non-blocking. dows Education 10.0.19041 both running on a Dell laptop. We observed outbound traffic to third-party global and local 2) Leak Classification: We consider all outgoing traffic that destinations. On Windows, we observed non-CPD traffic to is not required for VPN setup as leakage. However, the low- Microsoft hosts as well as to third-party hosts. level protocols ARP, EAPOL, DHCP, ICMP, IGMP, LLMNR, In the following sections, we present the findings of our and mDNS are not considered leakage. We further distinguish analysis of the native VPN clients, the macOS API and third- leakage to hosts operated by the platform maintainer (e. g., party VPN clients. The results are summarised in Table II and Apple for iOS and macOS, or Microsoft for Windows) from will be discussed in Sec. VI-F. leakage that is going to other third-party hosts. C. Native VPN Clients 3) General Test Procedure: We test each VPN client in a captive network (denoted as captive mode) and in a unre- All tested operating systems ship with built-in clients that stricted network (open mode) as well as in a network that offer basic VPN functionality. Note that this analysis only selectively but permanently blocks, i. e. drops, the traffic to covers the functionality that is exposed by the OS’s native GUI the respective VPN endpoint (block mode). Note that in block (e. g., via a network settings dialogue) and not functionality mode, both the safe fail state requirement (R4) is tested, that is only exposed via APIs or configuration files. as well as the probability to detect potential race conditions 1) macOS and iOS: Although provided by system APIs during the VPN startup is increased. If a client does not offer (cf. Sect. V), always-on functionality is neither part of the auto-connect functionality, we instead manually activate the native VPN client on macOS (version 10.15.7) nor iOS (ver- connection before joining the testbed Wi-Fi. sion 14.0.1). VPNs set up via the on-board configurators have Each network configuration is tested and captured at least to be started manually while Internet connectivity is avail- three times while performing the following steps: 1) dis- able and do not always (re-)connect if network connectivity connect client device from Wi-Fi, 2) activate VPN client if is interrupted. Note that iOS additionally supports remotely deploying always-on VPN profiles via device supervision, necessary, 3) clear CP state and start capture, 4) connect client 8 to Wi-Fi, 5) complete CP sign-in if prompted, and 6) continue i. e. mobile device management. As we do not have the capture for 20 seconds. Afterwards, we inspect the captured necessary prerequisites for device supervision, this option was traffic and classify it according to our leakage definition. not included in our analysis. 8https://support.apple.com/en-gb/guide/deployment-reference- 7Using PixelExperience ROM version 10.0-20200912-1735 ios/iore8b083096/1/web/1 TABLE II goes online again before the VPN connection times out, we OVERVIEW OF THE VPN CLIENT ANALYSIS.SYMBOLUSAGE: RACE observed that CPD is suppressed and the system is in a CONDITION («), PLATFORM TRAFFIC LEAK (.), NOT TESTABLE (?), NOTAPPLICABLE (–) deadlock until the VPN timeout occurs, after which outbound traffic is unrestricted. Note, that before the timeout and in open mode, we also observed VPN bypasses by DNS lookups for Microsoft hosts like www.bing.com. Platform Client R1: Always-onR2: CPDR3: MinimalR4: BlockingR5: No Bypass macOS Native  –––– D. VPN API Demo Demo      EncryptMe      Platforms like macOS and iOS provide dedicated APIs that ExpressVPN   ()  ? Mullvad      supposedly offer blocking VPN bootstrapping. However, as ProtonVPN      they currently don’t integrate this functionality in their native iOS Native  –––– VPN clients, we implemented a minimal demo for macOS to EncryptMe   .   ExpressVPN   . ?  test the validity of the documented properties. We selected Mullvad      macOS for our demo because of previous development expe- ProtonVPN   . .  rience on that platform. Windows Native  ()––– EncryptMe      The demo builds on the Personal VPN API (cf. Sect. V) and ExpressVPN      simply registers an on-demand VPN that auto-connects with Mullvad      an NEOnDemandRuleConnect rule every time a Wi-Fi ProtonVPN      Android Native      connection is used. While testing our demo, we found that the EncryptMe  «    VPN tunnel is reliably started by the system after we connect ExpressVPN   .   to our test Wi-Fi. However, our traffic captures consistently Mullvad   .   ProtonVPN  «/ / / ./– show outgoing platform (towards Apple) and third-party traffic Ubuntu Native      between the CP authentication and the tunnel establishment ExpressVPN    ?  in both open and captive mode. The documented blocking      Mullvad feature of the NEOnDemandRuleConnect rule appears to be insufficient. We further found that after the tunnel estab- lishment, TCP traffic bypasses the tunnel that originates from 2) Android: The built-in VPN client [14] offers the option before the VPN establishment, i. e., for ongoing TCP streams. to turn on always-on VPN if the VPN server address is We also observed ongoing TCP re-transmission attempts that provided numerically and a DNS server is set. We found that started before the establishment. This corroborates a bypassing with always-on enabled, Android entered a captive deadlock. vulnerability that has been reported in March 2020 but remains Disabling the captive network allowed Android to establish unfixed (in Oct. 2020) [15]. In block mode, we observed the VPN tunnel. We found that apart from the CPD traffic, continued traffic to platform and third-party hosts after the TLS traffic was sent to www.google.com before the tunnel failed VPN connection attempts. The on-demand connection was established. Otherwise, no further traffic was leaked. rule appears not to sufficiently block on a failed establishment. 3) Ubuntu GNU/Linux: Ubuntu ships with NM as a VPN and networking client. Provided that a VPN profile is con- E. Third-Party VPN Clients figured, NM allows to set an always-on VPN profile per connection (e. g., an SSID) in the connection editor. In captive We additionally included the following third-party clients in mode and with auto-connect enabled, NM stops forwarding our analysis: ExpressVPN as the self-declared market leader, CPD requests, thus causing a captive deadlock. In open mode, EncryptMe as a benchmark used by [10], ProtonVPN as the VPN starts as expected. In any case, NM’s auto-connect Top 10 provider with open source clients and an active stand has no blocking effect and outbound traffic is unrestricted, in VPN leak prevention [15], and Mullvad VPN as an open both during establishment and if the VPN is unreachable. In source provider. fact, NM appears to react to ICMP notifications stating that 1) ExpressVPN: On Ubuntu, version 3.0.2.12 deadlocked the VPN destination is unreachable by setting the connectivity in captive mode. In open mode, we observed no leaks besides to offline, thus preventing further leaks. However, during the local traffic. Block mode tests were not practical because the time NM attempts to connect to the VPN, no restrictions are endpoint address switched unpredictably. We further found in place for other process to send traffic. In block mode, when that when the app enters a blocking “unable to connect” state, no ICMP notification is received because the VPN traffic is it could only be re-established with full leakage, despite using dropped, NM retains online connectivity until the VPN times the connect statement as described in the info text, which out, thus increasing the time for other processes to leak traffic. apparently temporarily disables the traffic block. 4) Windows: Windows 10’s built-in graphical VPN con- On iOS, we tested version 8.3.5 which uses the on-demand figurator is not able to set up an always-on VPN profile. API to automatically reconnect the tunnel once it is activated. However, we found that VPN connections are not immediately We found non-CPD platform traffic during CPD in captive disconnected if a network interface goes offline. If the network and open mode. Additionally, we saw TCP resets of previous platform connections bypassing the tunnel. No deadlocks 4) ProtonVPN: On iOS, version 2.2.4 offers always-on occurred. Block testing was skipped again. functionality that cannot be turned off. We observed non-CPD On macOS, version 7.11.6(6), according to network settings, platform DNS and IP traffic between remediation and tunnel does not use Apple’s on-demand API. In captive mode, we ob- establishment. We also found traffic to the global IP address of served leak-free deadlocks as the CPD is interrupted. In open our testbed gateway throughout the capture. Blocking the VPN mode, the CPD passes but the tunnel establishment repeatedly traffic exhibited the same leakage. We additionally observed fails to complete within the capture time. However, within that traffic to Akamai servers, presumably operating for Apple. time we found no leaks. In block mode, ExpressVPN holds On macOS in captive and open mode, ProtonVPN 1.7.2 outgoing traffic and prevents leaks. exhibited no leaks during remediation, but we subsequently On Windows, we tested version 9.1.0(258). In captive and observed non-CPD platform and third-party DNS and IP open mode, we saw non-CPD platform and third-party traffic traffic before tunnel establishment. After tunnel establishment, before remediation and tunnel establishment. In block mode, prior platform and third-party TCP streams and local traffic no additional leakage occurs. The windows client appears to continued. We also noted reverse DNS lookups of the test not sufficiently block startup leaks. client’s local IP address. In block mode, we saw the same On Android, version 9.0.40 deadlocked in captive leakage up to the point of the attempted tunnel establishment. mode without leaks except non-CPD platform traffic to After that, no further leaks were visible. www.google.com. In open mode, we saw the same leaks On Windows, version 1.17.3 does not connect automatically, but no deadlocks. Block mode caused no additional leaks. but can be started manually before connecting to the Wi-Fi. 2) EncryptMe: This client has been used as a benchmark In captive mode, no CPD requests are sent. The system is in by [10]. It offers VPN-activation based on network trustwor- captive deadlock. In open and block mode, we saw no leaks api.protonvpn.ch thiness. On macOS, we tested version 4.2.3 with activated but traffic to . auto-start and leak protection (OverCloak). We found platform On Android, we tested version 2.3.54.0. In captive mode, and third-party traffic leaks in open, captive and block mode we observed inconsistent behaviour: the CP request is either before VPN startup and afterwards. No deadlocks occur. suppressed and the system deadlocked, or sent before tunnel establishment alongside other platform traffic. This behaviour On iOS, we analysed version 4.4.4 with enabled auto-protect indicates a race condition in the CPD and VPN handling. In which uses iOS’s on-demand functionality. In open mode, the block mode, increased platform and third-party leaks appear. app shows non-CPD platform leaks. During captive mode, we In open mode, we observed platform traffic leaks throughout. also found continued platform traffic bypassing the VPN. In In its settings, ProtonVPN for Android contains instructions block mode, we saw no additional leakage. to activate always-on functionality by manually enabling An- On Windows, we analysed version 1.1.0. In captive mode, droid’s always-on and blocking VPN properties in the system we observed third-party leaks and no deadlocks. In open mode, VPN profile. With always-on enabled, captive and block mode the VPN establishment completes faster, hence we found fewer lead to a leak-free deadlock. Because the app explicitly guides and only platform leaks. However, blocking VPN traffic causes the user to that system feature, we also included these results. third-party traffic to surface again. Note that ProtonVPN also offers a command-line client On Android, version 4.2.0.1.81964 exhibits indeterministic for Linux, however we were unable to test it, because our captive deadlocking and third-party leaks, indicating a race credentials were rejected. condition between the CPD and the tunnel establishment. After blocking the VPN in captive mode, we observed consistent F. Summary and Discussion leak-free deadlocks. In open mode, we found no leaks. How- Of the native and third-party VPN clients in our analy- ever, blocking the VPN in open mode causes third-party traffic sis (see Table II), only Mullvad for iOS managed to establish to leak. A Linux version is not available. a connection in a captive network without deadlocks or traffic 3) Mullvad VPN: On iOS, version 2020.4 established a tun- leaks. On all platforms but iOS and macOS, an effective nel after remediation without leaks. A source code inspection leak protection coincided with deadlocks after a failed CPD. confirms that Mullvad uses the on-demand connection API. We identified issues with violations of the minimal startup Open or block mode cause no leaks either. requirement (R3) due to platform traffic leaks on Android On macOS, Windows and Ubuntu, we tested the respective and iOS, that appear to be related to system APIs making client in version 2020.5 and observed the same behaviour: exceptions for platform destinations in an otherwise effec- In captive mode, the clients caused a leak-free deadlock by tive leak prevention (esp. on iOS). The appearance of race suppressing the CPD traffic. In open and block mode, the client conditions on Android suggests that APIs do not sufficiently prevents leakage and we observed only VPN traffic. ensure a prioritised VPN startup or guide developers towards On Android, Mullvad is still in beta version (2020.6-beta2). secure API usage. We found and reported several issues In captive mode, CPD requests are sent and redirected, but to Apple, Google, and GNOME, including third-party leaks the request to the CP is lost, thus causing a deadlock. In open during macOS’s supposedly blocking on-demand connection mode, we observed non-CPD platform traffic before tunnel handling. We are continuing to report and discuss found issues establishment. Block mode triggers no additional leaks. with the other vendors. Fig. 1. Stage 1 selective VPN bypass: only CPD traffic is allowed Fig. 2. Stage 3: Only traffic to and from the VPN provider is allowed

Based on our analysis, we are convinced that a secure and confronted with CPs. We propose a concept that ensures a private VPN establishment, esp. in public Wi-Fi environments, leak-free VPN establishment in three stages and recommend relies on a deep integration with the OS and its CPD process. OS vendors to adopt the proposal. It therefore requires high-level system APIs that allow VPN REFERENCES clients to hook themselves into a multistage secure network startup process, which we detail in the following. [1] N. Cheng, X. Oscar Wang, W. Cheng, P. Mohapatra, and A. Seneviratne, VII.SELECTIVE VPN BYPASS FOR CAPTIVE PORTALS “Characterizing privacy leakage of public WiFi networks for users on travel,” in 2013 Proceedings IEEE INFOCOM. IEEE, pp. 2769–2777. We propose the following design for a secure VPN startup [2] N. Sombatruang, L. Onwuzurike, M. A. Sasse, and M. Baddeley, implementation. The process has to selectively allow outgoing “Factors influencing users to use unsecured wi-fi networks: evidence traffic in three stages: in the wild,” in Proceedings of the 12th Conference on Security and Privacy in Wireless and Mobile Networks. ACM, pp. 203–213. Stage 1: Captive Portal Detection: In this stage, as [3] W. A. Kumari, Ólafur Guðmundsson, P. Ebersman, and S. Sheng, depicted in Fig. 1, only outgoing CPD requests to a platform’s “Captive-Portal Identification Using DHCP or Router Advertisements predefined detection server should be allowed. Other outgoing (RAs),” RFC 7710, Dec. 2015. [Online]. Available: https://rfc- editor.org/rfc/rfc7710.txt traffic including communication with platform services should [4] Wikipedia. Captive portal. [Online]. Available: https://en.wikipedia.org/ be blocked. This could be implemented by restricting network- wiki/Captive_portal ing capabilities to a dedicated CPD process and a minimal, [5] S. Ali, T. Osman, M. Mannan, and A. Youssef, “On Privacy Risks of isolated web browser instance to complete the CP sign-in, or Public WiFi Captive Portals,” in Data Privacy Management, Cryptocur- rencies and Blockchain Technology, ser. Lecture Notes in Computer by setting up a firewall that blocks all outgoing traffic except Science, C. Pérez-Solà, G. Navarro-Arribas, A. Biryukov, and J. Garcia- to the CPD server and the CP. Alfaro, Eds. Springer International Publishing, vol. 11737, pp. 80–98. Stage 2: Always-on VPN Activation: After the captive [6] M. Ikram, N. Vallina-Rodriguez, S. Seneviratne, M. A. Kaafar, and V. Paxson, “An Analysis of the Privacy and Security Risks of Android network is successfully remediated, the system should trigger VPN Permission-enabled Apps,” in Proceedings of the 2016 ACM on the always-on VPN connection establishment and grant further Internet Measurement Conference - IMC ’16. ACM Press, pp. 349–364. networking capabilities to the VPN process or subsystem. [7] J. Wilson, D. McLuskie, and E. Bayne, “Investigation into the security If the VPN connection can be established successfully, the and privacy of iOS VPN applications,” in Proceedings of the 15th International Conference on Availability, Reliability and Security, ser. bootstrapping can continue with the next stage. Otherwise, all ARES ’20. Association for Computing Machinery. outbound traffic should remain blocked to avoid leakage and [8] M. T. Khan, J. DeBlasio, G. M. Voelker, A. C. Snoeren, C. Kanich, and the user should be notified. N. Vallina-Rodriguez, “An empirical analysis of the commercial VPN ecosystem,” in Proceedings of the Internet Measurement Conference Stage 3: Open Connectivity: After a VPN tunnel is 2018. ACM, pp. 443–456. established, the system can grant networking capabilities to [9] V. C. Perta, M. V. Barbera, G. Tyson, H. Haddadi, and A. Mei, “A all other applications and services, as depicted in Fig. 2. glance through the VPN looking glass: IPv6 leakage and DNS hijacking in commercial VPN clients,” vol. 2015, no. 1, pp. 77–91. VIII.CONCLUSION [10] R. Karlsson, “Ezmole: A new prototype for securing public wi-fi connections,” Master’s thesis, Luleå University of Technology, 2017. We are convinced that public Wi-Fis will continue to play [11] Apple. Personal VPN. [Online]. Available: https://developer.apple.com/ an important role in providing mobile Internet connectivity documentation/networkextension/personal_vpn in the future, whilst 5G and fast cellular networks become [12] ——. Packet Tunnel Provider. [Online]. Available: https://developer. apple.com/documentation/networkextension/packet_tunnel_provider more ubiquitously available and data plans more affordable. [13] ——. VPN On Demand Rules. [Online]. Avail- It is therefore important that OS vendors and VPN service able: https://developer.apple.com/documentation/networkextension/ providers equip their software to mitigate privacy risks caused personal_vpn/vpn_on_demand_rules by public Wi-Fi usage. Our analyses shows that the vast [14] Android Developers. VPN. [Online]. Available: https://developer. android.com/guide/topics/connectivity/vpn majority of clients are currently unable to provide VPN es- [15] Proton Team. VPN bypass vulnerability in Apple iOS. [Online]. Avail- tablishment without leaking traffic or causing deadlocks when able: https://protonvpn.com/blog/apple-ios-vulnerability-disclosure/