Method for detecting transit connections in a network

Abstract

A computer-implemented method for detecting relay connections in a network is disclosed.SOLUTION: The method includes receiving, at a server, a perceived indication of a client device, obtaining a geo-location associated with the perceived indication, determining a client-server value based on a transmission time of a connection signal transmitted between the client device and the server, determining an expected value associated with the geo-location, and establishing that a connection between the client device and the server is to be routed via the relayed connection if the client-server value exceeds a threshold value, wherein the threshold value is based at least in part on the expected value.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] A computer-implemented method for detecting relay connections in a network is disclosed. [Background technology]

[0002] A VPN (Virtual Private Network) is a mechanism used to create a secure connection between a computer / network and another network over an insecure connection medium (usually the public Internet). The connection is secured using a virtual PTP (point to point) connection to a secure server using a tunneling protocol. With a VPN, the original IP of the connecting client is obfuscated / hidden and the client is virtually connected to the target network.

[0003] Thus, VPN servers can run software that forwards network traffic while obfuscating the source of the communication. VPNs have many practical use cases, but they also have malicious ones. VPN servers can be used by malicious actors to hide their identities. Spoofing the source IP of a connection also effectively spoofs the client's location. Therefore, VPN / proxy detection is necessary to detect and prevent geolocation spoofing. VPN detection can be particularly important for services that use geolocation as a security element, such as zero trust infrastructure and fraud prevention services. The global zero trust security market is valued at $26.45 billion and is projected to reach $162.91 billion by 2032 (https: / / www.emergenresearch.com / industry-report / zero-trust-security-market(accessed May 19, 2024)). Similarly, the fraud detection and prevention market is expected to be worth $36.89 billion in 2022 and grow to $182.66 billion by 2030 (https: / / www.fortunebusinessinsights.com / industry-reports / fraud-detection-and-prevention-market-100231 (accessed May 19, 2024)).

[0004] Client obfuscation through the use of VPNs or proxy services can be a significant weakness of IP geolocation as a security factor. If a client connects to a server using a VPN, the IP observed by the server is the VPN's IP, not the client's own IP. This means that geolocation of the "client" IP address will instead return the location of the VPN server. This flaw can be used to effectively circumvent geolocation-based defenses. This obfuscation allows the client to essentially change its perceived geographic location, thereby gaining access to geo-locked services (such as government services, financial services, and content streaming). For these reasons, VPN detection is always a pressing issue for secure services that require a high level of trust.

[0005] Existing solutions for detecting when a VPN is being used by a client generally use passive solutions that maintain a rank / score of Internet Protocol (IP) addresses known to hold VPNs / proxies. For example, existing methods may use APIs that use known IP databases and behavioral analysis to detect VPN / proxy use. Some known services collect data over time and analyze communications in combination with publicly available information to create a risk score and proxy / VPN assessment. However, these methods are often not robust enough for truly sensitive services and can be bypassed.

[0006] It is therefore desirable to improve the ability of a service (from a server) to detect that a VPN is being used by a client (or client device). Summary of the Invention

[0007] The invention is defined in the independent claims, to which reference should now be made. Further features are set out in the dependent claims.

[0008] According to one aspect of the present invention, there is provided a computer-implemented method for detecting relayed connections in a network, comprising: receiving, at a server, a perceived indication of the client device; obtaining a geolocation associated with the perceived indication; determining a client-server value based on a transmission time of a connection signal transmitted between the client device and the server; determining an expected value associated with the geolocation; establishing that a connection between the client device and the server is routed through the relayed connection if the client-to-server value exceeds a threshold, the threshold being based at least in part on the expected value; A method is provided which includes: [Brief explanation of the drawings]

[0009] Reference is made to the accompanying drawings, which are used by way of example only: [Figure 1a] 1 shows an example of a configuration of a virtual private network within a network. [Figure 1b] The client-server handshake procedure, the client-proxy handshake procedure, and the client-VPN handshake procedure are shown. [Figure 2] 5 illustrates steps of a method for detecting relay connections in a network. [Figure 3] 1 shows a configuration for detecting a relay connection in a network. [Figure 4] 1 shows a flowchart of method steps for detecting relay connections in a network. [Figure 5] 1 shows a state diagram illustrating different states of a system / device implementing a method for detecting relayed connections in a network. [Figure 6a] 1 shows experimental results using the methods disclosed herein. [Figure 6b]1 shows experimental results using the methods disclosed herein. [Figure 6c] 1 shows experimental results using the methods disclosed herein. [Figure 6d] 1 shows experimental results using the methods disclosed herein. [Figure 6e] 1 shows experimental results using the methods disclosed herein. [Figure 6f] 1 shows experimental results using the methods disclosed herein. [Figure 7] Shows a plot of the RTT ratio between VPN / Direct Client and Landmark communication, aggregated at 10ms intervals. [Figure 8] 1 illustrates an architecture for implementing the methods disclosed herein. [Figure 9] 1 shows a block diagram of an information processing appliance or computing device or server. DETAILED DESCRIPTION OF THE INVENTION

[0010] The following definitions will help you understand the terms used throughout the discussion:

[0011] IP Geolocation, also known as network, internet, or device localization or geolocation, is the process of finding the geographic location of a connected device on the internet. That is, IP Geolocation is the process of identifying a device based on information that can be obtained or inferred using the device's IP address.

[0012] In the realm of internet security, IP geolocation is used either as an attack vector (profiling victims to lure them into attacks) or as a security element. This concept has gained momentum over the last decade (especially in the anti-fraud and zero trust markets). IP geolocation techniques can be broadly divided into three categories: passive, active, and hybrid. Passive technology leverages information that can be analyzed based solely on IP addresses, without the need to communicate directly with the device. Active approaches tend to use probes to measure the delay to the target. Based on the collected data and a delay-to-range model, an estimate of the target device's location is generated. Hybrid methods combine the two, using previous data collection and machine learning models to improve active measurement results.

[0013] A probe (also called a landmark, beacon or anchor) is a node with a known location that participates in the discovery process.

[0014] A virtual private network (VPN) is a mechanism for creating a secure connection between a computing device (client device) and a computer network, or between two networks, using an insecure communications medium such as the public Internet.

[0015] VPN servers / services (Virtual Private Network (VPN) services) provide proxy servers that help users bypass internet censorship such as geo-blocking, and protect users' communications from data profiling and MitM attacks on hostile networks.

[0016] RTT (round-trip delay (RTD), or round-trip time (RTT)) is the total time it takes for a signal to be sent and the time it takes for a response to acknowledge that the signal has been received. This time delay can include the propagation time of the path between two communication endpoints. For example, RTT can measure the time it takes for a network request to travel from its origin to its destination and back again. RTT duration can be measured in milliseconds (ms).

[0017] Provided herein is a computer-implemented method for detecting relayed connections in a network, the method comprising: receiving, at a server, a perceived indication of the client device; obtaining a geolocation associated with the perceived indication; determining a client-server value based on a transmission time of a connection signal transmitted between the client device and the server; determining an expected value associated with a geolocation; establishing that a connection between the client device and the server is routed through a relay connection when the client-server value exceeds a threshold, the threshold being based at least in part on the expected value.

[0018] The connection signals may be referred to as client connection signals, client originated signals, and / or control signals. The perceived indication information may be referred to as position indication signaling, position information, and / or information indicating a position.

[0019] The expected value may be an expected round trip time of a virtual signal transmitted between a virtual device and a server at a geolocation. The expected value may be determined from the geolocation and the propagation speed of the virtual signal. The virtual device may be a virtual client device or a virtual probe. The virtual signal may be an example of any signal transmitted between a server and a virtual device. The expected round trip time may be the time it takes for the virtual signal to be transmitted from the server / virtual device to the virtual device / server and for an acknowledgment to be transmitted back to the server / virtual device.

[0020] The expected value is a server-probe value related to a transmission time of a probe signal transmitted between a server and a probe, the probe being the closest probe to a selected geolocation from one or more probes, which may form a probe network.

[0021] The client-server value may include the client-server round trip time of a connect signal. The client-server value may also be referred to as the server-client value. The client-server (or server-client) round trip time may be the time it takes for a connect signal to be sent from a server / client device to a client device / server and for an acknowledgment of the connect signal to be received by the server / client device.

[0022] The expected value may include the server-to-probe round trip time of the probe signal sent between the server and the probe. The server-to-probe round trip time is sometimes referred to as the (probe-to-server round trip time). The server-to-probe round trip time may be the time it takes for a probe signal to be sent from the server / probe to the probe / server and for an acknowledgment of the probe signal to be received by the server / probe.

[0023] The client device may be a user equipment (UE), a personal computer, a terminal device, etc. The client device may be connected to the Internet, for example, via an Internet service provider.

[0024] The perceived indication may be an Internet Protocol (IP) address, for example, an IPv4 or IPv6 address.

[0025] The connection signals sent between the client device and the server may be at least one of Transmission Control Protocol (TCP) handshake signals, Secure Sockets Layer (SSL) handshake signals, and Transport Layer Security (TLS) handshake signals. The connection signals may transmit TCP, SSL, and / or TLS data packets.

[0026] Other connection signals may be transmitted and the client-server value may be based on transmission times of the other connection signals, which may be TLS handshake signals and / or SSL handshake signals.

[0027] The connection signal may be a TCP handshake signal, and the other connection signal may be at least one of a TLS handshake signal and an SSL handshake signal.

[0028] The client-server value may include an average round trip time, where the average client-server round trip time is an average of the client-server round trip time of the connection signal and the other round trip time of the other connection signal. The client-server value may be the longer of the client-server round trip time and the other (client-server) round trip time.

[0029] The connection signals may be separated into different packets and transmitted separately. The length of the TCP / TLS / SSL handshake may be extended accordingly. Each packet may be transmitted as a separate connection signal.

[0030] The client-server value may further be related to the cryptographic signal round trip time between the server and the client device. The client-server value may be related to the cryptographic signal in that the cryptographic signal may be taken into account when determining the client-server value or may be used in the client-server value.

[0031] The client-server value may be calculated from an average including the client-server round trip time and the cryptographic signal round trip time. The client-server value may be determined as the longer of the client-server round trip time and the cryptographic signal round trip time.

[0032] During cipher negotiation with a client device, the server can be configured to reject cipher configurations proposed by the client. The server can determine the cipher round-trip time from additional ciphers sent by the client device. Preferably, the additional ciphers can be sent using a "ChangeCipherSpec" packet.

[0033] The probe signal may be an Internet Control Message Protocol (ICMP) Ping, a Transmission Control Protocol (TCP) (handshake) signal, or a Transport Layer Security (TLS) (handshake) signal.

[0034] The expected server value may include a further server-probe value associated with the second probe. Multiple probes may be used to determine the expected server value. The further server-probe value may be the round trip time of the further server-probe.

[0035] The calculated value can be determined using at least the following formula: [LS_RTT+CLS_RTT]+[(D_cp+GE) / ω] where LS_RTT is the expected value, C is a constant preferably between 0 and 1 and / or C is the relative error margin of detection of LS_RTT, D_cp is the distance between the geolocation associated with the perceived indication and the probe or virtual device, GE is the geolocation expected error associated with the geolocation determination, and ω is the expected propagation speed of the signal transmitted between the server and the client device.

[0036] The confidence level associated with the threshold can be calculated as follows: Confidence=min((CS_RTT-LS_RTT-[(D_cp+GE) / ω]) / (CLS_RTT),1) or Confidence=(CS_RTT-LS_RTT-[(D_cp+GE) / ω]) / (CLS_RTT)

[0037] The relay connection may be a virtual private network connection, a Tor connection, a proxy connection or a tunneling connection.

[0038] According to another aspect, there is provided herein a computer program product that, when executed on a computer, causes the computer to perform a method for detecting relayed connections in a network, the method comprising: receiving, at a server, a perceived indication of the client device; obtaining a geolocation associated with the perceived indication; determining a client-server value based on a transmission time of a connection signal transmitted between the client device and the server; determining an expected value associated with a geolocation; establishing that a connection between a client device and a server is routed through a relayed connection when a client-to-server value exceeds a threshold, the threshold being based at least in part on an expected value; Includes:

[0039] According to yet another aspect, there is provided herein an information appliance for detecting a relay connection in a network, the information appliance including a memory and a processor coupled to the memory, the processor: Obtaining a geolocation associated with the perceived indication; determining a client-server value based on a transmission time of a connection signal transmitted between the client device and the server; determining an expected value associated with geolocation; A connection between the client device and the server is established to be routed through the relay connection when the client-server value exceeds a threshold, the threshold being configured to be based at least in part on the expected value.

[0040] Advantageously, the methods described herein can improve the accuracy and speed of VPN detection. Furthermore, the methods can provide detection of private / new VPNs (which traditional solutions often cannot detect).

[0041] Another aspect of the embodiment includes a computer program that, when executed by a computer / computing device / teleconferencing device, causes the device to perform the method of the embodiment. The computer program may be stored on a computer-readable medium. The computer-readable medium may be non-transitory.

[0042] Another aspect of the present invention includes a computer program that, when executed by a companion device, causes the companion device to perform the method of the embodiment. The computer program may be stored on a computer-readable medium. The computer-readable medium may be non-transitory.

[0043] The invention can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The invention can be implemented as a computer program or computer program product, i.e., a computer program embodied in a non-transitory information carrier, such as a machine-readable storage device or a propagated signal, for execution by or controlling the operation of one or more hardware modules. The computer program may be in the form of a stand-alone program, a computer program portion, or multiple computer programs, and may be written in any type of programming language, including compiled or interpreted languages, and may be deployed in any form, such as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a data processing environment.

[0044] The present invention has been described in terms of specific embodiments. Other embodiments are within the scope of the following claims. For example, the steps of the invention can be performed in a different order and still achieve desirable results.

[0045] Those skilled in the art will understand that, unless mutually exclusive, a feature described in connection with any one of the above embodiments may also be applied mutatis mutandis to any other embodiment. Furthermore, unless mutually exclusive, any feature described herein may be applied to any embodiment and / or combined with any other feature described herein.

[0046] FIG. 1a shows an example configuration 100 of a virtual private network 110 within a network. The VPN connects a client device 120 to a (web) server 130. The client device is, for example, a computer / network / any device that has access to the Internet. The server can be any device or computer program that provides information to the client device. The information can be, for example, a "service" or a "resource." In other words, the client device and the server can function in a client-server model. The VPN can create a secure connection between the client device and the web server (which can be an insecure medium such as the Internet).

[0047] A VPN can obfuscate / hide the original (true) location 125 of a client device. A device can be geolocated using the IP address associated with the device. Thus, a VPN can "hide" the location of a client device by replacing the client device's IP address with a VPN IP address. In other words, a VPN can obfuscate the client device's (user's) true location by masking the client device's (user's) IP address. A web server communicating with the client device can receive the VPN IP address instead of the client device's IP address. However, the IP address received by the web server is recognized as coming from the client device. Thus, if the web server attempts to locate the client device 120 using the IP address, it will instead determine the VPN's location (VPN geolocation 115). In this example, the server is referred to as a web server, but of course, any suitable server could be used.

[0048] 1a also shows an unsecured client device 140. In this example, the web server can identify the unsecured client device if the web server uses the IP address of the unsecured client device to locate the unsecured client device.

[0049] Traditional methods use behavioral analysis and IP ranking approaches to detect the use of VPNs as relay connections between client devices and servers in a network. There are several solutions for server-side proxy / VPN detection, each with its own advantages and disadvantages. Here, we will only consider detection methods that can be performed from the server side. In these examples, the service being accessed performs the detection and can only access the communication from the client after it has passed through the VPN / proxy.

[0050] Known solutions can be divided into two major categories. The first is a passive approach, typically based on a known IP database (DB). The DB can include behavioral analysis data and reputation scores based on reports and passive data collection. Passive data includes raw packet captures at key junctions, offline port scans, and source analysis. Some known methods include Maxmind, SEON, and IPQualityScore. The inventors found that these approaches require large amounts of data and time to analyze communications and establish a baseline for analysis. Passive VPN detection methods can detect VPN usage with an accuracy of up to 95–99%. However, passive detection methods require prior knowledge for detection and may fail for private or new VPNs until they are updated (as discussed below).

[0051] The second approach is an active detection approach that has multiple techniques.

[0052] Scanning for Active Ports and Services: Popular VPN solutions / services have default ports and protocols that can be scanned to determine if the VPN service is running on the server. When a connection is initiated on the server, ideally a scan of the source IP can determine if the client is using the VPN. The inventors have found this method to be non-robust, as the ports and protocols used can be switched in non-default configurations, potentially causing false positives.

[0053] Deep Packet Inspection: Because VPNs completely encapsulate the original packet, the size available for data within the packet can change, potentially resulting in several detectable changes in the Transmission Control Protocol (TCP) header. Specifically, the maximum transmission unit / maximum segment size (MTU / MSS) field in the header can deviate from the standard. This limitation also leads to further changes in the data size and other characteristics of received packets over time. Deep packet inspection can be implemented on the server using any sniffing tool (i.e., a tool used to capture data transmitted between the client device and the server). However, the inventors identified several problems with this approach. Anomalies in TCP fields can be (and have been) resolved with simple configuration / implementation changes. Anomalies in packet content are inconsistent and require a significant number of packets and complex machine learning models to identify with sufficient accuracy.

[0054] Delay and RTT Measurement: Delay anomaly measurements have been implemented to detect proxies (proxy servers) using RTT measurements of the TCP handshake compared to the TLS handshake or application layer communication. Other, more intrusive methods can involve running JavaScript code that creates a new connection to a server (or multiple servers). While this technique has proven effective in detecting proxies, it does not consistently detect VPNs. This is because (as explained earlier) VPN services without extensions encapsulate the entire communication, which does not result in significant differences in RTT measurements for different protocols or applications.

[0055] A known approach for proxy detection, developed by Elisa Chiapponi et al. (Chiapponi, E., Dacier, M., Thonnard, O., Fangar, M., Rigal, V. (2022). BADPASS: Bots Taking ADvantage of Proxy as a Service. In: Su, C., Gritzalis, D., Piuri, V. (eds) Information Security Practice and Experience. ISPEC 2022. Lecture Notes in Computer Science, vol. 13620. Springer, Cham.), uses the difference in round-trip time (RTT) of TCP and TLS handshakes to determine whether a proxy is being used. This method can detect the use of a proxy with up to 99% accuracy, but it cannot detect VPNs or proxies that do not "drop" the TCP connection, which does not always happen with VPN connections, such as VPN solutions that implement the core OpenVPN protocol (see Figure 1b).

[0056] Previous methods (Hoogstraaten, H.: Evaluating server-side internet proxy detection methods (Msc Thesis) (2018), AT Webb and AL Narasima Reddy, "Finding proxy users at the service using anomaly detection," 2016 IEEE Conference on Communications and Network Security (CNS), Philadelphia, PA, USA, 2016, pp. 82-90, doi: 10.1109 / CNS.2016.7860473) also proposed using HTML tags to generate additional consecutive connections to measure multiple RTTs. These methods require modifying the site on the server, which is not ideal for non-disruptive deployment. Furthermore, the method proposed by Webb et al. requires a significant amount of training and data for detection and does not solve the same problem of VPN detection for VPN tunnels that do not necessarily drop TCP connections.

[0057] Furthermore, the inventors have discovered that using the existing approaches described above, new or privately used VPNs may not be detected initially and may take a relatively long time to detect (if at all). Furthermore, VPN services can adapt to this analysis method, periodically changing their behavior, location, and IP address to avoid detection with minimal effort. For example, malicious cybersecurity attacks almost always hide their source location. One of the best and most effective ways to do this is to use a VPN, ideally a private VPN server that is not from a well-known VPN service. In this case, behavioral analysis and IP rankings would be virtually useless in detecting this type of VPN use, as there would be little information to analyze upon initial use.

[0058] Further limitations of known IP geolocation techniques include: Passive geolocation techniques require large amounts of ground truth data to achieve sufficient accuracy; active techniques require significantly less data but are much more susceptible to network outages, potentially resulting in significant errors; the inventors have established that a fundamental assumption of IP geolocation is that the IP address presented by the target device is the IP assigned to the user's device; using VPNs and proxies to obfuscate the client's IP negates geolocation security; this tends to be true for all IP geolocation techniques, as both passive and active techniques rely on this fundamental assumption; to compensate for this, some IP geolocation techniques include some degree of server-side VPN / proxy detection as a countermeasure.

[0059] Solutions can be incorporated into the authentication process to use geolocation as a security element. In practice, user experience is not significantly impacted by load times or false-positive errors. Perhaps most importantly, security standards must be maintained. This requires extremely high accuracy and extremely fast detection speeds. These standards can quickly invalidate passive approaches. Passive approaches are very fast, but they require the use of databases and behavioral analysis, which requires prior knowledge and significant data collection. When encountering new, non-mainstream VPN servers, passive approaches are essentially always likely to obtain false negatives, making them unacceptable from a security perspective. As mentioned above, port scanning tends to be unreliable and easily evaded. Deep packet inspection combined with machine learning approaches shows promise, but to date requires a lot of communication flow data to be effective, which tends not to be available during the login process.

[0060] A technical application of VPN detection methods is the zero-trust security model, which relies on IP geolocation as an additional security element. Specifically, multi-factor authentication (MFA) providers use IP geolocation to grant or deny access to specific users based on their location or to implement additional security restrictions when users attempt to log in from unusual locations. Using Microsoft Azure conditional access policies (https: / / learn.microsoft.com / en-us / entra / identity / conditionalaccess / location-condition; accessed February 10, 2024), organizations can block users from accessing services from countries or regions where the organization does not operate. Furthermore, the proliferation of national and international laws regarding data and user protection (e.g., GDPR) requires certain data to be kept within specific boundaries.

[0061] The inventors identified the following challenges in developing a reliable and secure VPN detection solution: VPNs are intentionally hidden. VPNs are intentionally used to hide the client's location, so they always operate undetectably. By modifying servers / procedures and improving security, Accuracy: Failure to detect can have serious consequences on the security of the service and the user experience. · Speed: The detection must be as fast as possible, as it must not affect the user experience. · Resilience: How well can detection be maintained under attacker threat?

[0062] FIG. 1b shows a client-server handshake procedure 150, a client-proxy handshake procedure 160, and a client-VPN handshake procedure 170.

[0063] As mentioned above, a VPN allows for private connections over public networks. This can be implemented by encapsulating and encrypting packet data sent from the client. The packet data is depacketized at the VPN server and sent as if it originated from the VPN server. When the response returns to the server, it is encapsulated, encrypted, and sent back to the client. This method hides the client's original IP address from the services it is accessing, or allows access to an internal network while encrypting sensitive data over a public network.

[0064] An HTTPS proxy creates a secure connection on the transport layer. When a client connects to the proxy, all HTTPS requests are routed through the proxy server, which obfuscates the client IP. Client requests are sent to the proxy over TCP, which means that the TCP connection is "broken" with each new connection. Therefore, both the client and the server create a TCP handshake (Client-Proxy Handshake 160).

[0065] Both VPNs and proxy servers may hide the client's IP address. However, detecting VPN traffic poses unique challenges not addressed by proxy detection techniques. VPNs can be considered proxies that operate at the network layer rather than the transport layer. This means that, unlike HTTPS proxies, TCP connections are not necessarily dropped. The differences between direct, proxy, and VPN handshakes are illustrated in Figure 1b. The core implementation of a VPN server (e.g., OpenVPN protocol RFC https: / / openvpn.net / communityresources / openvpn-protocol / (accessed March 12, 2024)) encapsulates and tunnels all packets generated by the client and does not interrupt the handshake sent to the server (Client-VPN Handshake 170). This tunnel creates a barrier to previous solutions in detecting VPN usage. Some VPN services essentially function as proxies because the TCP handshake is broken but the TLS handshake is tunneled. This can be seen in use by NordVPN (https: / / nordvpn.com / (accessed February 10, 2024)) and ExpressVPN services (https: / / www.privateinternetaccess.com / (accessed February 10, 2024)). This method is an effective form of obfuscation, as the RTT measured over a TCP connection is the same as the RTT measured by connecting directly to the VPN server.

[0066] The VPN servers mentioned above also tend to respond to pings, meaning that the communication RTT appears to match direct RTT measurements, making the servers appear benign to a naive detection approach. VPN services that use SSL decryption (usually corporate VPNs such as Palo-Altos GlobalProtect) instead interrupt the TLS handshake, making the TLS RTT shorter than the TCP RTT.

[0067] 2 illustrates steps in a method 200 for detecting relayed connections in a network. In this example, the relayed connection may be a proxy connection, such as a VPN. The method developed by the inventors deviates from the previous behavioral analysis approaches described above. The method leverages objective indicators of proxy communication that can be detected immediately and consistently from the first use of a VPN server.

[0068] The use of a VPN introduces additional delays in communications based on the physical distance between the client and the VPN server. The method disclosed herein can detect the additional delays in responsive and unresponsive VPN server communications. That is, the method for VPN (relay connection) detection can use direct delay measurements of client communications from the server side. VPN servers are often configured to be "hidden" and therefore may not respond to probe signals. The method described herein can circumvent this issue by communicating with a probe that is selected based on IP geolocation and therefore has a similar RTT to the VPN server. Additionally or alternatively, the RTT of a location can be estimated from geolocation and known propagation speeds of signals in different regions / locations.

[0069] Furthermore, the indicators identified by the inventors are not behavioral and therefore virtually impossible to adapt. Considering the example of private VPN servers used to hide cyber attacks, the methods described herein can immediately detect VPN usage where traditional solutions fail or take a significant amount of time.

[0070] The method for detecting a relay connection in a network may include the following steps.

[0071] In a receiving step S10, the server can receive the perceived indication information of the client device. The perceived indication information may be an IP address. The IP address may be, for example, IPv4 or IPv6. If a relay connection is active or in use between the client device and the server, the indication information may be information belonging to the relay connection. The indication information may be, for example, an IP address of the relay connection. The relay connection may be a VPN. Thus, the relay connection may be an IP address of the VPN.

[0072] In an example where the client device does not use a relay connection, the perceived indication information may be information belonging to the client device (client device indication information). In one example, the indication information may be an IP address of the client device (client device IP address). This indication information may be referred to as perceived indication information in that the server may not know whether the indication information is from the client device or whether the information is from a relay connection.

[0073] The obtaining (or determining) step S20 may obtain a geolocation associated with the perceived indication. The geolocation may be obtained using a geolocation service. For example, the perceived indication may be mapped to a physical location. A geolocation database or application programming interface (API) may map the indication to a location such as a country, region, city, latitude, longitude, etc. The geolocation database or API may be queried to obtain the geolocation associated with the indication. In one example, the indication is an IP address, and the geolocation associated with the IP address is geolocated using IP-based geolocation technology.

[0074] In the determining step S30, a client-server value based on the transmission time of a connection signal transmitted between the server and the client device can be determined. The client-server value may be, for example, the round-trip time of a connection signal transmitted between the client device and the server. For example, the client may transmit an initial connection signal to the server. The server may transmit an acknowledgement (Server ACK) to the client device and start a timer. The timer may be stopped when the server receives an acknowledgement (Client ACK) return signal from the client device.

[0075] The connection signal may be any suitable signal having characteristics for determining a client-server value. For example, the connection signal may be a TCP handshake signal between a client device and a server. For example, the client device may initialize a TCP connection with the server by sending a TCP:SYN (TPC synchronize) signal. The server may send a TCP SYN+ACK signal as an acknowledgment of the signal sent by the client device. The client device may send an additional acknowledgment (TCP ACK) of the signal sent by the server.

[0076] The client-server value (which may be a value determined between the client and server or between the server and client) may be, for example, the TCP RTT measured using a TCP handshake. The TCP RTT may be measured as the interval between the server sending the TCP SYN+ACK packet and receiving the client TCP ACK packet.

[0077] Following the TCP handshake, an additional (or different) connection signal may be sent. The additional connection signal may be a TLS handshake signal. The client-server value may be determined from an average of the TCP RTT and the TLS RTT, or may be determined using the longer or shorter of the TCP RTT and the TLS RTT signal. For example, the longer RTT may be used because it is assumed that the signal with the longer RTT arrives at the client device and the shorter RTT may indicate a VPN disconnection. The TLS handshake may be used to determine the TLS RTT as follows: That is, the TLS handshake may be used for the additional RTT measurement. In another example, the additional connection signal may be an SSL handshake signal, and the client-server value may be calculated as described above using the RTT of the SSL signal.

[0078] The inventors used a sniffing tool to measure TCP and TLS ( / SSL) handshakes. That is, the client-server values ​​can be determined using a detection server. The detection server can run the sniffing tool. The detection server can receive signals sent between the client device and the server.

[0079] During the TLS handshake, the client device can send a client "hello" packet to the server. The server can respond with a server "hello" packet. The TLS RTT can be determined as the interval between the server hello packet sent by the server and the next TLS packet received from the client. The next TLS packet can contain, for example, either a change cipherspec or a TLS appdata flag, depending on the TLS version used in the communication. The above TCP and TLS communication is shown in Figure 1B.

[0080] We have confirmed that both sources (TCP RTT and TLS RTT) can be used to measure the client's RTT. In different implementations (as mentioned above), some of the communication is cut off at the VPN / Proxy server and not tunneled, which may result in false negatives when used to detect VPN usage.

[0081] The inventors have found that upon detection, tunneled RTTs can be significantly longer than dropped communications originating from the VPN server rather than the client. While VPNs that drop TCP connections can be detected as proxies using previous solutions, the inventors have found that previous solutions do not provide a consistent solution for detecting all VPN and proxy usage.

[0082] Four TCP and TLS RTTs can be measured from (each) client, and then the median and minimum RTTs can be taken for the TCP and TLS measurements. We used four RTT measurements, but any suitable number can be used. Measuring four RTTs can address different VPN connection types and mitigate errors / noise. The RTT of the protocol with the longer median RTT can be used as the client-server value.

[0083] Additionally or alternatively, the connection signals sent between the server and the client device may be secure socket link (SSL) packets (or TLS packets, depending on the version used by the web server). That is, the client device and server can run a TCP connection as usual without measuring the RTT. The RTT measurement can start from the TLS handshake. For example, depending on the VPN protocol / service, either TCP and / or TLS and / or SSL measurements can be used.

[0084] Multiple connection signals may be sent between the server and the client device. Multiple signals may be sent, for example, to ensure that the RTT is measured as many times as possible to determine statistically significant results. To send multiple signals, the length of the handshake between the server and the client device may be extended. The inventors have discovered that the length of the handshake may be extended by separating each step of the handshake into a different packet. This differs from typical handshake techniques, which attempt to integrate as many steps as possible. Each packet may be sent as a separate connection signal.

[0085] Additionally or alternatively, the client-server value may be associated with (or based on) additional TLS communications, e.g., the round-trip time of cryptographic signals between the server and the client device. For example, during cryptographic negotiation between the server and the client device, the server may be configured to reject a cipher proposed by the client. The cryptographic round-trip time may be determined from additional cryptographic packets sent by the client device. That is, by rejecting a cipher proposed by the client device, the client device may send an additional cipher, e.g., a "ChangeCipherSpec" command / packet. The round-trip time may be determined from the cryptographic signals. For example, the client-server value may be determined by calculating an average round-trip time from the RTTs associated with SSL packets and the RTTs associated with the cryptographic signals. Additionally or alternatively, the client-server value may be determined from an average of any combination of RTTs, e.g., TCP and SSL, TCP and TLS, TCP and crypto, TLS and crypto, SSL and crypto, TCP and TLS and crypto, etc. Alternatively, the client-server value may be determined as the longer or shorter of the RTT signals. It is therefore understood that a client-server value determined based on the transmission time of a connection signal transmitted between a client device and a server may represent a client-server value that includes a value associated with the connection signal (i.e., the RTT), or the connection signal may be taken into account in the determination but not used, for example, when additional or further connection signals are used, i.e., the connection may still be used in the determination step as it may be compared with the further / additional connection signals to determine if the connection has a longer / shorter RTT.

[0086] Although TCP and TLS measurements were used to measure RTT, of course, any other suitable signals could be used, for example higher layer measurements and / or generated recursive requests could be used to measure RTT.

[0087] The client-server value can be determined on the server side or on the client side, for example, depending on the limitations of the service. On the server side, the RTT can be determined using raw packet analysis of the TCP handshake and further TCP / TLS communication. On the client side, JavaScript can be used to communicate with the server and calculate the RTT. Using JavaScript can allow for the analysis of more communication in a controlled way to obtain more accurate results.

[0088] In determining step s40, an expected value related to the geolocation may be determined. The expected value may be, for example, an expected round trip time of a virtual signal transmitted between the virtual device and a server at the geolocation. The expected value may be determined from the geolocation and the propagation speed of the virtual signal. That is, based on the geolocation and known propagation speeds in different regions, an expected RTT for the communication may be determined.

[0089] Additionally or alternatively, the expected value may be a server-probe value associated with a probe signal transmitted between the server and the probe. The probe may be selected from one or more probes and may be the probe closest to the geolocation. Additionally or alternatively, the probe may be within a threshold distance of the geolocation. The probe may be a node, landmark, or beacon configured to communicate with the server.

[0090] As noted above, a probe may be selected from multiple (available) probes. The probe may be the probe of the multiple probes that is closest to the geolocation and therefore may be selected to communicate with the server. Multiple probes may be selected. For example, 1 to 3 probes may be selected, although of course any number of probes may be selected. As noted above, probe selection may be based on proximity to the geolocation. In the method developed by the inventors, geolocated RIPE Atlas probes (RipeAtlasprobes https: / / atlas.ripe.net / (accessed February 25, 2024) were used to generate approximate RTT measurements for VPNs.

[0091] The expected value may include a server-to-probe round trip time of a probe signal transmitted between the server and the probe. In examples where multiple probes are used, the expected value may be an aggregate value from each expected value of each probe. For example, the expected value may be the aggregate round trip time of each probe signal transmitted between the server and each probe.

[0092] Probe signals include, for example, Internet Control Message Protocol (ICMP) PING, TCP handshake, or Transport Layer Security (TLS) handshake. The type of probe signal depends on the protocol supported by the probe. Some protocols may be blocked in certain instances. For example, a network security policy may require that ICMP ping (ICMP echo reply) be disabled on all devices. Therefore, ICMP ping cannot be used to determine RTT. Nevertheless, the inventors have discovered that each protocol has the same or substantially the same effectiveness when calculating the RTT of a probe signal sent between a server and a probe.

[0093] We measured the RTT from the server to the three nearest available landmarks using direct ICMP pings. The minimum RTT from the ping was chosen to ensure the stability of the direct connection and to filter out slow landmarks. This measurement method works with successful TLS authentication, and edge-case exceptions are easily implemented, for example, through server-side control. Therefore, client controls that do not directly correlate with actual use cases do not introduce undue bias.

[0094] In an establishing step S50, a connection between the client device and the server may be established to be routed through a relayed connection if the client-server value exceeds a threshold value, which may be based at least in part on an expected value.

[0095] In one example, the threshold may be an expected value. The client-server value may be compared to the threshold, and if the client-server value is greater than the threshold, it may be determined that the connection between the client device and the server is routed through a relay connection. The threshold may be a scaled value of the expected value. For example, the expected value may be multiplied (or divided or acted upon) by a constant to generate the threshold.

[0096] The inventors have found that an effective threshold can be defined as follows:

number

[0097] Therefore, the following formula can be used to determine that a connection between a client device and a server is routed through a relay connection:

number

[0098] As mentioned above, the constant C may be set between 0 and 1. This may be changed depending on how tightly the threshold should be set. Alternatively, the constant may be the relative error margin of detection based on the client RTT. Details for determining the relative error margin are described in connection with Figure 7 below.

[0099] In this example, the client-server value (i.e., the perceived client RTT) can be significantly larger than the RTT from the nearest geolocated probe, taking into account the distance and standard deviation between the probe and the actual client / VPN Server.

[0100] The confidence level of the detection (i.e., the determination that a relay device is present) is determined by the CS RTT is based on the distance between the process and the normalized distance of the process, which can be expressed using the following formula:

number

[0101] Alternatively, the trust level can be determined as follows:

number

[0102] Using the above confidence formula, the confidence level of a detection is directly related to the number of standard deviations the RTT difference is equal to. The threshold can be modified to set the tolerance level according to specific requirements. For example, the confidence level can be used by customers (or clients or users) of a service implementing the methods described herein to set their own tolerance level of accuracy. Using the above formula, the inventors have determined that the median and minimum RTT (LS RTT ) were generated. The results of both options were analyzed and the detection with the higher confidence level was selected and is described below.

[0103] The method disclosed herein can utilize the physical limitations of communication on the Internet (or other distributed networks) to determine whether a VPN / proxy is being used by a client. The round trip time (RTT) of communication on the Internet is affected by multiple factors, including hardware, software, and communication infrastructure, but the most important factor is usually (in modern infrastructures) the actual physical distance between the client and the server. The use of a VPN server can add a relatively constant and significant amount of time to the RTT of a communication. This is primarily caused by the physical distance between the client and the VPN server. The challenge is to identify whether the additional delay exists.

[0104] This detection method is developed based on the passive TCP / TLS RTT measurement approach. This method has minimal requirements from the server and may have no code running on the client. The problem of no "interruptions" (i.e., TCP disconnections) in the tunnel connection is circumvented by communicating with geolocated landmarks (probes) in the immediate vicinity of the client's known location. This method allows for accurate and real-time active detection of VPN connections.

[0105] 3 shows an arrangement 300 for detecting relayed connections 310 in a network. In this example, the relayed connections may be proxy connections such as VPNs.

[0106] As mentioned above, communication through a VPN server can incur additional delays based on the distance between the client (sometimes referred to as secure client 320) and the VPN server, and the distance between the VPN server and the server (e.g., web server 330). Therefore, the RTT can increase significantly. The inventors have discovered that the RTT expected from communication with the VPN server's IP (i.e., the VPN's geolocation, VPN geolocation 315) can be significantly less than that measured when the client (secure client) is hidden behind the server. On the other hand, if the client (unsecure client 340) communicates directly with the server, such additional RTT may not exist.

[0107] A possible attempt to measure whether an RTT difference exists is to communicate directly with the VPN server (or client if no VPN is used), measure the RTT of the communication, and compare it to a communication originating from the client. However, the inventors have identified a problem with this method: VPN servers (especially malicious ones) often actively attempt to obfuscate their status, thereby blocking all communication. This means that direct measurement of the RTT of a VPN server may be essentially impossible.

[0108] The method disclosed herein avoids this potentially significant problem. The inventors have found that with today's advanced technology, a useful assumption is that the RTT between the client and the VPN, and from the VPN to the server, is primarily driven by physical constraints, specifically the physical distance that packets must travel.

[0109] In most cases (e.g., when the client and server are far from each other), hardware / software limitations may be negligible in the RTT calculation. Based on these assumptions, trusted machines (probes 350, 360) that are geographically close to the VPN / client can be used to approximate the RTT from the VPN server / client to the server. In this case, geographically close may be within the same town, city, country, or within a set distance (e.g., radius), such as 10 km, 100 km, 500 km, or 1000 km.

[0110] The inventors have discovered that IP geolocation can be used to determine a client's perceived location (either its true location or the location of a relay connection, if one is used). State-of-the-art IP geolocation solutions can reach city-level accuracy, which the inventors have discovered is more than sufficient to detect relay connections within a network. VPN servers are typically used to hide a client's true location. This means that a VPN server located in another country or at least another city is likely to be used. Once the communicating IP address (i.e., the perceived indicative information) is geolocated, one or more probes closest to that location can be deployed. Probes are deployed if they are within a geolocation threshold distance 352 (indicated by a dashed circle in the figure). As noted above, the threshold distance may be, for example, 10 km, 50 km, or 100 km.

[0111] The probes 350, 360 may have known locations 355, 366 and may be distributed across a city, country, and / or the world.

[0112] Looking at the client communication to the web server over the VPN, the communication is split into three sections: Tcs is the full delay from the client to the server. Tcv is the latency from the client to the VPN. Tvs is the delay from the client to the VPN, essentially Tcs = Tcv + Tvs, with Tcv = 0 if no VPN is used.

[0113] If you try to measure Tvs, the expected result will be the same as Tcs. There is almost no chance of accessing Tcv from the server side. The discovery process may essentially try to prove that Tcv is a non-zero value. This can be proven by measuring Tcs and Tcv.

[0114] To measure Tcs, we measured the TCP and TLS handshake RTT. VPNs attempt to hide or obfuscate their presence as much as possible. There are multiple ways to do this, but a simple way is to ignore all incoming communications that the server does not know about. A simple approach to actively measure the RTT from a server to a VPN is to simply ping it. However, even if the server responds to a ping request, the RTT measurement is not necessarily reliable.

[0115] With full control over the VPN server, we can spoof or randomize the delay to match the client. To address the issue of intentional obfuscation by VPNs, we implemented a method to indirectly measure the expected delay difference using a trusted source. The basic assertion was that with modern network infrastructure and endpoint hardware, network delay is almost entirely determined by the physical distance between the communicating network endpoints (in this example, the client, VPN, and web server). If a large difference in RTT between Tcs and Tvs is measured, the client may be detected as being farther away from the server than indicated by its IP address. Thus, if this assertion is true, delay measurements from a landmark geographically close to the VPN and the detection server would produce results very similar to the expected Tvs value.

[0116] The inventors have found that with current passive geolocation technology, city-level accuracy can be expected in most urban areas, and country / region-level accuracy in the remaining regions (country mismatches are very rare). Using passive IP geolocation with the perceived client IP typically returns a good approximation of the client or VPN geolocation (we have found that an expected error of 100-200 km has negligible impact on delay measurements on an international scale). The returned geolocation can be used to find geographically nearby landmarks using ground truth services like RIPE Atlas. These landmarks (probes) can be pinged directly, and the measured RTT can be used to obtain an acceptable approximation of Tvs.

[0117] As described above, a probe may be used to measure the RTT between the probe ( / proxy) and the server (server-probe RTT, Tvs). If there is a significant difference (determined, for example, using Equation 2) between the client communication RTT (client-server RTT, Tcs) and the probe RTT, it may be determined that a relay connection (i.e., VPN communication) is being used (i.e., detected). For example, if Tcs >> Tvs, it may be determined that a VPN is being used. If Tcs ≈ Tvs, it may be determined that a VPN is not being used.

[0118] The present inventors have discovered that two types of probes can be used to exploit geolocation information. 1. Active Probing: It utilizes a network of controllable geolocated probes and generates communications from those probes to calculate the RTT between the server and the probes. 2. Landmarks: These machines are geolocated machines that are considered trustworthy and can be directly communicated with (can be thought of as passive probes).

[0119] Additionally or alternatively, inference-based techniques can be used to determine the expected round trip time. The expected round trip time can be considered as the round trip time of a virtual signal transmitted between a virtual device (or virtual probe) and a server at a geolocation. The expected round trip time may be determined from the geolocation and the propagation speed of the virtual signal. That is, for example, a database can store the expected round trip time of a signal transmitted from a server to a region / location. Based on the geolocation and known propagation speeds in different regions, the expected RTT of the communication can be estimated, and the expected RTT can be compared to the perceived RTT using Equation 2. As described above, if there is a significant difference (Equation 2) between the client communication RTT and the estimated RTT, it can be determined that a relayed connection (i.e., VPN communication) is being used (i.e., detected).

[0120] As an example, the method disclosed herein can run the detection server along with any running server / service that it has permission to run (e.g., a web server). The method for detecting VPNs can include the following steps: 1) A client initiates a communication to a web server. The initial communication is analyzed to calculate the full client-to-server delay, defined as Tcs above. The RTT is measured using the TCP and / or TLS handshake (described above). 2) The client IP is geolocated and nearby probes / landmarks are located using e.g. the RIPE ATLAS API. You can select the three geographically closest responding probes (landmarks). 3) The RTT to landmarks is measured using ping (and / or other probe signals) and aggregated to produce a good estimate of Tvs. 4) A decision is reached using the measured RTT and a calculated error margin based on the measured Tcs value.

[0121] Both TCP handshake RTT and TLS handshake RTT can be measured multiple times per client. Accessing a web server from a base image / JavaScript tag may trigger multiple requests. Base image / JavaScript tags are a necessary part of any website, with the additional assumption that the requested artifacts are not cached (additional requests may be triggered by additional tags, including img / javascript / iframe etc).

[0122] FIG. 4 shows a flowchart 400 of method steps for detecting a relay connection in a network. In this example, the relay connection is a VPN connection between a client device (an Internet computer) and a server. That is, when the client device communicates with the server, it can route data through the relay connection. A client device may be a "host" device and may be referred to as a client if it runs an application (e.g., a web browser, an email agent, etc.) and requests services from a server. A relay connection may be a host device and may be referred to as a relay connection if it accepts requests from a client and forwards the requests to another host device (which may be a server). A server may be a host device and may be referred to as a server if it provides (Internet) services to clients. Those skilled in the art will understand that a client device can indirectly connect to a server (e.g., a web server) by first connecting to a network connected to the Internet (a connected network). The connected network can then grant the client device access to the Internet.

[0123] In client communication block 410, initial communication between the client and server may be performed (or set up). For example, the client device (or relay connection, if used) may query the server. The query may be, for example, a request for information or data, or a TCP handshake request. The server may obtain perceived indicative information from the client device. For example, the server may obtain an IP address associated with the client device.

[0124] In IP geolocation block 420, a geolocation associated with the IP address may be determined / obtained. The geolocation of the client (or relay connection) may be determined using a geolocation service. For example, the geolocation may be obtained by querying a lookup table having IP addresses and locations associated with IP addresses. Different geolocation services may be available, and the most appropriate or available geolocation service may be used. Based on the geolocation method used, an expected error range for the location result may be determined or ascertained.

[0125] In probe selection block 430, based on the geolocation of the indication information, a database containing the probe locations may be searched and the probe / probes closest to the geolocation may be selected. For example, 1 to 3 probes may be selected. The closest available probe may be selected based on a geographic distance calculation and / or availability tests. Since a reliable connection and a reliable source of the probe may be required (e.g., regarding security or exact location), the probe may belong to a private collection of probes or may be from a reliable source such as the RIPE Atlas.

[0126] In the probe execution RTT measurement block 440, an expected value associated with the obtained geolocation can be determined. In this example, the expected value is the round trip time of the signal sent between the server and the probe. Depending on the probe's support for different protocols, the RTT may be measured using ICMP PING / TCP handshake / TLS handshake. The expected value measurement may be initiated by the probe or the server. The measurement may be initiated by the probe, depending on the control of the probe and whether the probe is considered a trusted probe. Assuming the probe is trusted, the result is expected to be the same if the measurement is initiated by the probe or the server.

[0127] In the client communications collection block 450, data packets (e.g., signals) may be sent between the server and the client device (or relay connection). These signals may be used in the client RTT measurement block 460, described below. The VPN / relay connection may be configured to block any probe signals. The inventors have discovered that the packets that almost certainly reach the client device (i.e., if a connection exists between the client device and the server over the network) are SSL handshake packets. Thus, the client communications collection block may include receiving an SSL connection signal from the client device and waiting for an acknowledgement / negative acknowledgement (ACK / NACK) signal when the server sends the SSL signal back to the client device.

[0128] The client device may be further probed by refusing to negotiate encryption between the client device and the server, thereby triggering the client device to send further encrypted packets / information.

[0129] In the client RTT measurement block 460, a client-server value associated with a connection signal transmitted between the server and the client device may be determined. In this example, the client-server value is the round-trip time associated with the connection signal. The connection signal may be transmitted from the client to the server, and an ACK / NACK may be transmitted from the server to the client in response. The time it takes to transmit the signal from the server and receive the signal back from the client (e.g., an ACK / NACK response) may be analyzed to calculate the RTT from the client to the server. That is, in the client RTT measurement block, an analysis of the communication between the client device and the server may be performed to determine the RTT.

[0130] Communication to the server can be analyzed on the server side or on the client side, depending on the limitations of the service. On the server side, the RTT can be determined using raw packet analysis of the TCP handshake and further TCP communication (i.e., analysis of the probe signal). On the client side, JavaScript can be used to communicate with the server and calculate the RTT. Using JavaScript may allow analysis of more communication in a controlled way to obtain more accurate results.

[0131] In client-to-probe RTT analysis block 470, the client-to-server value (i.e., client-to-server RTT) and the server-to-probe value (i.e., server-to-probe RTT) are compared and analyzed. The RTTs are compared, for example, using Equation 2 above.

[0132] In VPN detection result + trust level block 480, a result is determined of whether a relay connection (i.e., a VPN) is being used. The result may be a binary result, for example, a VPN is being used or a VPN is not being used. If the client-to-server RTT is greater than the server-to-probe RTT, it may be determined that a VPN is being used. As above, the result may be determined using Equation 2.

[0133] Along with the determination, a confidence level / score may also be calculated. For example, a confidence score can be calculated for Equation 3 or Equation 4. The confidence level can be directly related to the number of standard deviations within which the RRT difference is equal.

[0134] Although the actions performed by each block above are described sequentially, the blocks may be performed in any suitable order / concurrently, for example, the client-server RTT may be calculated, then the server-probe RTT, or the RTTs may be determined simultaneously.

[0135] Although the method is described in the context of detecting VPN usage, it can be adapted to identify other types of proxy communications ( / relay connections), including proxy / Tor / tunneling solutions, depending on the technology used. Additionally, the probe itself can be used for active geolocation purposes, depending on the amount of control / access available to the probe.

[0136] The method described herein employs an active approach to VPN detection, solving the problem of VPNs being intentionally hidden. Because the method does not rely on prior knowledge or ranking of a device's connecting IP, it may be significantly more reliable and accurate than existing methods. The method may use an aggregation of delay measurements from probes geolocated near the source IP (i.e., perceived indicators). The measurements can be used to identify delay discrepancies caused by communications tunneled through a VPN.

[0137] Unlike other solutions, the method uses globally distributed probes to detect additional delays. This allows VPN server detection based entirely on current behavior and does not require prior knowledge. Leveraging (trusted / controlled) probes for VPN detection minimizes the need for interaction with clients or VPN servers. In most cases, VPNs do not respond to probes directly (e.g., VPNs are intentionally hidden). Therefore, the method disclosed herein can improve reliability and accuracy compared to other known solutions. Furthermore, the method can instantly detect previously unknown VPNs that cannot be detected by methods using ranks and stored IP addresses.

[0138] 5 shows a state diagram illustrating different states of a system / device that performs the method described herein. An example implementation of this method will be described in relation to the state diagram.

[0139] In "Wait for New Client Communication" block 510, the server may be idle, i.e., ready to be queried by a client device. The server may be a web server with the following credentials: IP:20.117.181.32 Geolocation: London, England "51.5085,-0.1257" The geolocation of the server may be known or may be determined using the server's IP address.

[0140] In "IP Geolocation + RTT Analysis" block 520, the server may receive the client device's IP address (or perceived IP address). In this example, the client device is routed through an intermediate connection, specifically a VPN. The server may receive the client device's perceived IP address (i.e., VPN IP address), and the IP address may be geolocated. The IP address may be geolocated by the server, or forwarded / sent to another system / device to be geolocated. The VPN may have the following authentication information: VPN Server: IP:20.67.232.30 Geolocation: Dublin, Ireland "53.3331,-6.2489"

[0141] The client device can transmit connection signals that can be used to determine the RTT time, which can be determined from multiple connection signals by taking the average value calculated for each probe signal.

[0142] In the probe RTT measurement block 530, the system can determine / select one or more probes within a threshold distance of the geolocation. Additionally or alternatively, the system can select one or more probes from one or more probes closest to the geolocation. The system can initiate communication (e.g., wireless communication) with the probe and obtain the probe's IP address. In this example, one probe was used. The perceived IP address obtained from the client device originated from Dublin, Ireland, so the system selected a probe in the same geographic area. The probe's authentication information is as follows: probe: IP:20.67.232.30 Geolocation: Dublin, Ireland "53.3331,-6.2489"

[0143] As described herein, a probe may be probed with a probe signal to determine the RTT associated with the probe at that geolocation (server-probe RTT).

[0144] In this example, the client may be in Israel, but its location is not detected or used.

[0145] In VPN detection decision block 540, the system can determine whether the client device is using a VPN connection when communicating with the server. The system can use the following information determined in the previous blocks in making the determination: [Table 1]

[0146] The variables in the table are defined with reference to Figure 2 and are repeated as follows: CS_RTT is the (median) RTT associated with the probe signal sent between the server and the client device; LS_RTT is the aggregated RTT between the probe and the server; std is the standard deviation of the LS_RTT; C is a constant (0-1) that varies depending on how strict the threshold is set (and / or may be based on the size of the LS_RTT); D_cp is the distance between the probe and the geolocation associated with the perceived indication (e.g., the VPN IP address in this example); GE is the geolocation prediction error based on the geolocation method used to determine the geolocation from the IP address; and ω is the predicted propagation speed of the signal sent between the server and the client device based on the geolocated region associated with the perceived indication. The predicted propagation speed may be a known value used as an approximation of the maximum propagation speed possible in modern networks.

[0147] Using Equation 2 above, the system can arrive at the following results and confidence levels:

number

[0148] As can be seen from the results, even though the probe and the VPN server are essentially geolocated in the same place, the RTT of the communication is significantly different due to the significant delay (as expected) added by the client behind the VPN server, and therefore the system is able to detect that the connection between the client device and the server is routed through a VPN.

[0149] 6a-6f show experimental results using the methods disclosed herein.

[0150] To prove the effectiveness of the method disclosed herein, the inventors conducted tests with several known VPN services (NordVPN, PIA, ExpressVPN), each of which has a slightly different implementation of known state-of-the-art solutions, including: OpenVPN: A robust, mature, open-source protocol that is an industry standard (OPENVPN Protocol RFC https: / / openvpn.net / communityresources / openvpn-protocol / (accessed March 12, 2024)). · IKEv2 / IPSec: Focuses on security using strong cryptographic algorithms (IKEv2 Protocol RFC https: / / datatracker.ietf.org / doc / html / rfc5996 (Accessed: March 12, 2024)). WireGuard / NordLynx / lightway: Still experimental, but already in use due to its superior security and speed improvements (WireGuard protocol https: / / www.wireguard.com / papers / wireguard.pdf (accessed March 12, 2024); Nordlynx protocol https: / / nordlayer.com / blog / nordlayer-introducesnordlynx-protocol / (accessed March 12, 2024); expressvpn lightway protocol https: / / www.expressvpn.com / lightway (accessed March 12, 2024)).

[0151] The methods disclosed herein have been tested with each service and each available protocol.

[0152] Client-server locations were diversified by setting up multiple Azure / AWS virtual machines (VMs) in various regions around the world. Three servers and VPN clients were configured using Azure (located in the UK, US, and Singapore), and 20 direct clients were configured in Azure / AWS. For the direct clients, the inventors were limited by the number of regions available in the cloud environment. Due to the limitations on direct clients, VPN clients were also limited to maintain a reasonable detection rate. Due to the large number of VPN locations available, using three clients ensured that a sufficient number of unique detection conditions could be generated. The detection server included a simple Flask web server (flask python https: / / flask.palletsprojects.com / en / 3.0.x / (accessed February 25, 2024)) and an additional packet sniffing script that communicated results with the detection server. Both were implemented using Python 3. The geolocation service used was the ipinfo geolocation API (ipinfo geolocation service https: / / ipinfo.io / products / ip-geolocationapi (accessed March 12, 2024)). The detection method was configured to run completely separately from the services running on the (web) server, but in parallel with the server with packet sniffing privileges. To accommodate connections to the VPN service from remote machines and maximize connection reliability, the inventors created an automation script using Chrome-Driver and Selenium with various VPN services and a Linux client application. The client script was configured to connect to a random VPN server from the selected VPN service every few seconds and contact the detection server using Selenium. The client sent its original IP address, as well as the service and protocol used. This information was used to verify the detection results and for further analysis.The direct client used the same chrome-based system via a direct connection.

[0153] The inventors have identified the following experimental limitations regarding reliability and connectivity: Reliability of RIPE Atlas probes: Atlas probes may be controlled by third parties and therefore may not be directly controlled, and their setup conditions may vary. Therefore, probes may not always be reliable and may have significant lags relative to the expected communication latency for that region. To account for this, areas / regions or probes with statistically significant variations in latency or increased lag / deviation compared to the expected communication time can be detected and excluded and / or addressed over time.

[0154] Other considerations: Skewed Data Set: The inventors discovered that the most important factor for clients was their physical location. Multiple VPN services were used, providing access to tens of thousands of servers in a wide range of locations around the world. No such (legal) service exists for Direct Client. Therefore, the inventors configured Direct Client using regions available in Azure / AWS cloud services. The inventors tested the method using available cloud services. Geolocation Reliability / Spoofing: The methods disclosed herein use passive IP geolocation techniques. The speed and accuracy of these services can affect measurements. The inventors have found that for most error ranges up to 100km, differences in RTT are likely insignificant, but can affect detection results for more severe errors and spoofing. Geographical distribution of clients: The clients used by the inventors were deployed in cloud data centers with limited geographical distribution.

[0155] The inventors discovered that each VPN client connected to a random configuration of services, protocols, and available regions at varying intervals (timing varied depending on the service used; for example, NordVPN required a longer timeout due to automatic throttling). Direct clients made new connections every 40 minutes, using known limits on available locations to generate useful direct connection data. Network conditions (e.g., congestion) can change over time based on multiple conditions. Therefore, collecting data in this manner was useful for analysis, even when not ideal. Data was collected from February 13, 2024, to April 18, 2024, and over 160,000 connections with over 32,000 unique IPs and corresponding locations were analyzed. The data was stored in Azure SQL Server, with each detection given a unique record in the detection information table and the client connection information table, which were then combined for analysis (the detection mechanism did not have access to the client data).

[0156] Each connection from a client could contain unique fields, and only those fields were added to the client database. This method filtered out detections that were not triggered by a client. The sniffing tool was configured to restart every 15 minutes and limit each unique IP to one detection within that time frame.

[0157] A useful correlation to verify the first claim is the measured client-server RTT versus the distance traveled. This is shown in Figure 6a, which plots the measured client RTT with the standard deviation error against the aggregated endpoint distance (client-VPN-server). The correlation is a good linear fit (R of 0.96). 2 ), the results validate our initial assertion that the total travel distance between endpoints contributes most significantly to the RTT of a communication.

[0158] Based on the same argument, we expect that when a VPN is used, there will be a significant difference in the measured RTT between the client and the landmark, while the difference will be minimal for direct connections. Figure 6b shows a histogram of the RTT difference for VPN connections. Figure 6c shows the RTT difference between VPN and (SNITCH) landmark communication and direct connections. The RTTs for direct client and (SNITCH) landmark communication are different (here, SNITCH stands for Server-side Non-intrusive Identification of Tunnelled Characteristics, which refers to the method disclosed herein). The relative RTT difference ratio was calculated as (CS_RTT-LS_RTT) / LS_RTT. Significant differences between VPN and direct connections can be seen in the figure. The median RTT difference for VPN connections is 124%, while the median RTT difference for direct communication is 2%. Further analysis revealed that more than 97% of VPN connections had a relative RTT difference of at least 10%. In contrast, only 0.6% of direct communication cases had such a difference. As expected, the difference in RTT for direct communication is close to zero, and is much more pronounced for VPN communication.

[0159] As shown in Figures 6b and 6c, some of the measured RTT differences returned negative values. These are rare cases of widespread network delays in the landmark communication, which could be caused by, for example, random packet drops or congestion. The fact that negative values ​​exist indicates the impact of significant (but very rare) network delays.

[0160] We performed an analysis of the detection results, taking into account a skewed dataset (as mentioned above) with many more unique VPN connections than direct connections, using precision, F1, and True Negative Rate (TNR) as detection rate metrics. Furthermore, we found that the network infrastructure of VPN server clients or VPN regions below modern standards significantly impacts the detection method. Therefore, we analyzed the detection confusion matrix for each continent. The detection performance metrics are visualized for each continent. See Figure 6d: Detection metric scores based on VPN and direct client locations. The metric scores used are precision, F1, and TNR. The data clearly reveal the effect of network infrastructure in less developed regions (South America, parts of Asia, and Africa). Furthermore, we see a significant improvement in reliability in more developed regions (North America, Europe, and Oceania). Performance is good in these regions, with precisions above 95%.

[0161] Another way to visualize the effect of network infrastructure is through a comparison of detection metrics, shown in Figure 6e: Median Detection Metric Scores for Download Speed. The metric scores used are precision, F1, and TNR. This is based on a median analysis of download speeds from speedtest.net. We classified countries with download speeds above 100MB as fast, above 60 as medium, and below 60 as slow. This visualization also clearly shows the impact of slow infrastructure. Identifying the direct cause of unreliability in these regions can be difficult. The VPN / client dataset described here is not perfectly representative of each region, and issues may arise from malfunctioning or connectivity issues with specific Atlas probes.

[0162] As an additional factor to the binary detection value, the confidence value can be used to set the detection threshold. Performance matrices for binary detection were generated for 0.5 confidence and full confidence, as shown in Figure 6f (detection confidence threshold metric score comparison, the metric scores used are accuracy, F1, and TNR).

[0163] The inventors found that increasing the confidence threshold improves detection performance, but detection entries whose confidence value does not meet the specified confidence threshold are discarded. When detecting all communications with a confidence level of 0.5, the results are accuracy: 0.945, F1: 0.971, and TNR: 0.992. When detecting in countries with high-speed networks with a confidence level of 0.5, the results are accuracy: 0.961, F1: 0.979, and TNR: 0.993.

[0164] The inventors were unable to find statistically significant differences in detection rates between the services tested or when different protocols were used. These results (while acknowledging the limitations of the experiment) indicate that server-side VPN detection using geolocated landmark RTT measurements is effective and a viable option for security services.

[0165] The method disclosed herein provides VPN (i.e., relay connection) detection based on RTT measurements and IP geolocation. While this method focuses on VPN detection, it can be used to detect any type of "proxy" (e.g., proxy, VPN, SSH forwarding, TOR, etc.). The initial assertion that there is a direct correlation between traveled distance and RTT, as well as the assertion that there is a significant difference between the RTT of VPNs and direct communications, hold true. As mentioned above, the detection method may not require significant changes to existing services. For example, it could use only multiple initial connections (e.g., TCP or TLS; this requirement is met by most servers that load JavaScript, images, or icons).

[0166] This method can provide the ability to run additional sniffing tools and detection servers, which can be implemented as simple add-ons that do not affect the original server.

[0167] The method described here is directed to VPN detection. However, the method can be used for any connection technology, including any type of "proxy" (proxy, VPN, ssh forwarding, TOR, etc.). Ideally, a complete VPN detection service could aggregate multiple existing solutions. A hybrid (passive and active) approach could increase the reliability of detection results and potentially improve over time.

[0168] The methods herein have been shown to be consistent across different services, protocols, and modern network infrastructures. A potential limitation of the detection methods disclosed herein is insufficient distance. As shown, RTT can be directly correlated to traveled distance. Therefore, if the client and VPN server are very close geographically (i.e., in the same city / region), it can be difficult to detect VPN usage with an adequate margin of error to account for typical network jitter and congestion. Geolocation-based Domain Name System (DNS) entries and diverse server locations can be used to ensure ideal conditions for detection of all direct clients and improve VPN client conditions without impacting the user experience (the distance between the client and the VPN is typically inaccessible to the detection server). However, if the VPN server is geographically close to the client, IP geolocation may produce a reasonably accurate geolocation for most security or regulatory purposes.

[0169] Another potential limitation is network infrastructure. Based on experimental measurements, we found that countries with slow median download speeds appear to have large deviations in network latency, with significant differences in latency between residential and corporate network connections. This may be due to outdated network infrastructure, which can cause high packet drop rates and low bandwidth. Beyond a certain threshold, detection may become unreliable. Implementations of the method disclosed herein can manually exclude regions with slow download speeds or other related metrics to increase reliability. Proactive detection of slow / outdated network infrastructure based on prior knowledge or measurement variance can be used to trigger more measurements, potentially impairing the user experience but ensuring security. This method can also be used to detect malfunctioning landmarks.

[0170] The method described herein provides a server-side method for detecting VPN connections. The detection method can use real-time TCP / TLS handshake RTT measurements and direct RTT measurements from geolocated landmarks. The method is simple to implement and has been shown to be effective with some of the world's most popular VPN services. In modern network infrastructures, overall accuracy rates of over 94% and precision rates of 96% have been achieved. Further steps to improve detection rates and ensure detection conditions are discussed.

[0171] Figure 7 shows a plot of the RTT ratio between VPN / Direct Client and Landmark communication, aggregated over 10 ms intervals. The graph is aggregated over 10 ms for deviation analysis and clarity.

[0172] To determine the error margin (e.g., for use in Equation 2 above), the relative difference in RTT measured between the client and landmark communications was analyzed for both direct and VPN communications. The inventors found that there is no consistent difference between the landmark and client RTTs, and that a relative margin approach is more likely to produce accurate detection.

[0173] The graph in Figure 7 shows the ratios from the directional deviation analysis to find the exact margin. VPN traffic has a ratio of at least 0.3 for all traffic, which is the one-way standard deviation from the mean. For direct client traffic, we observed a drop in the directional deviation from 0.3 for small RTTs to about 0.1 for large RTTs.

[0174] It was determined that minimizing false negatives is more important for accurate VPN detection than allowing for some false positives. Therefore, the error bounds were adjusted to be as close as possible to the upper bound of direct communication. The best fit found by the inventors was a logarithmic function. Of course, other functions can be used and can depend on the reliability of the probe / landmark-server RTT.

[0175] The logarithmic function was used with a lower limit of 0.1.

number

[0176] The lower bound was chosen to account for the typical jitter in Internet communications, which becomes less important at large RTTs and can be accounted for at smaller RTTs.

[0177] 8 illustrates an architecture 800 for implementing the methods disclosed herein. As described above, the client device may communicate with a web server. The web server may be connected to a network 810, such as the Internet or any other distributed network.

[0178] The server can obtain an IP address for the client device. The IP address can be the client device's public IP address (sometimes called an external IP address). The public IP address can be an IP address that is directly accessible via the Internet. The public IP address is assigned by an Internet Service Provider (ISP), for example, to a network router. The client device can communicate with the network router via a private IP address. The private IP address can be shared with the network router but remains private or hidden from the public or external network (i.e., the Internet).

[0179] The (public) IP address can indicate the location of the client device. A trusted service with geolocation 820 can use the public IP address to obtain the geolocation of the client device. As mentioned above, the IP address can be referred to as a perceived indicator, since the web server receiving the IP address may not know whether the IP address originated from the client device or was routed through a relayed connection.

[0180] An apparatus, e.g., a detection server, that performs the methods described herein can include a geolocation orchestrator 824. The geolocation orchestrator can be a block of code that implements an IP geolocation service. The geolocation orchestrator can link the trust-enhanced geolocation service with a VPN detection service 827. In this example, the VPN detection service is named "SNITCH (Server-side Non-intrusive Identification of Tunneled Characteristics)."

[0181] To detect the use of a VPN, the method can use a probe or probe network 830. Once the geolocation of an IP address is obtained, the probe or probes closest to that geolocation are launched. Examples of probes that can be used include RIPE ATLAS, PerfSonar, ProbeAPI, proprietary probes, etc. The RTT of the probe signal sent between the server and the probe can be determined. Thus, it can be determined whether the client device is using a relayed connection, as described in connection with FIG. 2.

[0182] The proposed method for detecting VPN use, called "SNITCH" (Server-side Non-intrusive Identification of Tunneled Characteristics), can be performed without requiring intrusive software running on the client. This method aligns with the themes of reliable networking and robust localization. In particular, robust localization can increase network reliability by leveraging physical features (i.e., geolocation). Using IP geolocation and reliable ground truth landmarks in combination with communication latency measurements, VPN and proxy usage can be accurately detected. Measurements can be performed in real time at the initiation of a connection to the server. Measurements can be performed on a detection server running in parallel with the server. This method allows VPN detection to be seamlessly integrated into the authentication process with little impact on the client experience. The results discussed in Figures 6a–6f show that SNITCH can detect VPN use with an accuracy of over 96% in areas with modern network infrastructure and maintains an accuracy of 94% across the measured areas.

[0183] 9 is a block diagram of an information processing appliance 900, such as a (data storage) server, or computing device 900, or server 900, that may be used to embody the present invention, to perform some or all of the operations of the methods embodying the present invention, and to perform some or all of the tasks of the apparatus of the embodiments. The computing device 900 may be used to implement any of the method steps described above, for example any of steps S10 to S50.

[0184] Computing device 900 includes a processor 903 and memory 904. Optionally, the computing device also includes a network interface 907 for communicating with other such computing devices, such as other computing devices of embodiments of the present invention. Optionally, the computing device also includes one or more input mechanisms, such as a keyboard and mouse 906, and a display unit, such as one or more monitors 905. These elements may facilitate user interaction. The components may be connected to one another via a bus 902.

[0185] Memory 904 may include a computer-readable medium, which term may refer to a single medium or multiple media (e.g., centralized or distributed databases and / or associated caches and servers) configured to carry computer-executable instructions. Computer-executable instructions may include, for example, instructions and data that are accessible by a computer (e.g., one or more processors) and cause it to perform one or more functions or operations. For example, computer-executable instructions may include instructions for implementing the methods disclosed herein or any method disclosed herein, e.g., steps S10-S50. The term "computer-readable storage medium" may include any medium capable of storing, encoding, or retaining a set of instructions for execution by a machine and causing the machine to perform any one or more of the method steps of the present disclosure; therefore, the term "computer-readable storage medium" includes, but is not limited to, solid-state memory, optical media, and magnetic media. For example, but not limited to, the term "computer-readable storage medium" may include solid-state memory, optical media, and magnetic media. By way of example, and without limitation, such computer-readable media may include non-transitory computer-readable media including random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disk storage devices, magnetic disk storage devices or other magnetic storage devices, flash memory devices (e.g., solid-state memory devices), and the like.

[0186] The processor 903 is configured to control a computing device and to perform processing operations, such as executing computer program code stored in the memory 904, for example, to perform any of the method steps described herein. The memory 904 stores data that is read and written by the processor 903, and may store at least one IP address-geolocation database, a probe database (i.e., a database of available probes / nodes), and / or formulas (e.g., formulas 1, 2, and / or 3), and / or any of the blocks described above, and / or programs for performing any of the method steps described above. These entities may be in the form of code blocks that are called as needed and executed within the processor.

[0187] As referred to herein, a processor may include one or more general-purpose processing devices, such as a microprocessor, a central processing unit, etc. A processor may also include a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. A processor may also include one or more special-purpose processing devices, such as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), a network processor, etc. In one or more embodiments, a processor is configured to execute the operations and instructions for performing the operations discussed herein. The processor 903 may be considered to include any of the blocks, units, or modules described above. Any operation described as being performed by a block may be implemented as a method by a computer, e.g., the processor 903.

[0188] The display unit 905 may display a representation of data stored and / or generated by the computing device, such as a determination of whether a connection between a client device and a server will be routed through a relay connection. The output may be displayed as GUI windows and / or interactive representations that allow a user to interact with the device 900 through selection dialogs, input text boxes, and / or any other output described above, and may also display cursors and dialog boxes and screens that allow interaction between a user and programs and data stored on the computing device. The input mechanism 906 may allow a user to input data and instructions into the computing device. For example, the display unit may display a GUI that includes a user panel or input space for the user to interact with. The user may enter a query about whether a connection will be routed through a relay device. The user may interact with the GUI and display to generate and view the determined answer. Of course, this method may be performed automatically without user interaction.

[0189] The network interface (network I / F) 907 can be connected to a network such as the Internet and can be connected to other such computing devices and / or servers via the network. The network I / F 907 can control input and output data to and from other devices via the network. Other peripheral devices such as a microphone, speakers, printer, power supply unit, fan, case, scanner, tracker ball, etc. may also be included in the computing device.

[0190] Methods embodying the present invention may be performed on a computing device / appliance / server 900 such as that shown in FIG. 9. Such a computing device need not have all of the components shown in FIG. 9, but may consist of a subset of these components. For example, device 900 may include a processor 903 and a memory 904 coupled to processor 903. Alternatively, device 900 may include a processor 903, a memory 904 coupled to processor 903, and a display 905. For example, the functionality and / or architecture described in connection with FIGS. 4 and 5 may be stored in memory, and / or the method described in connection with FIG. 2 may be stored in memory. The processor may be configured, for example, to use the functionality and / or architecture stored in memory to execute the method stored in memory.

[0191] Methods embodying the present invention may be performed by a single computing device / server communicating with one or more (data storage) servers via a network. The computing device may be a data storage device that stores at least a portion of the data. The functionality and / or architecture and / or method may be stored in one or more data storage servers, and a processor within the computing device may be configured to perform the method steps. As an example, step S10 of FIG. 2 may be performed by a (web) server that receives instruction information from a client device. The server may forward / pass the instruction information to a computing device / apparatus / server (i.e., detection server) 900 that performs the remaining method steps S20-S50. Alternatively, method steps S10-S50 may be performed by a (web) server.

[0192] Methods embodying the present invention may be performed by a plurality of computing devices operating in cooperation with one another, one or more of which may be data storage servers that store at least some of the data, for example, the IP address-geolocation database and / or the probe database may be stored on a server separate from other blocks, units or modules.

[0193] The invention can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The invention can also be implemented as a computer program or computer program product, i.e., a computer program embodied in a non-transitory information carrier, for example a machine-readable storage device or a propagated signal, for execution by, or to control the operation of, one or more hardware modules.

[0194] A computer program may be in the form of a stand-alone program, a computer program portion, or multiple computer programs, may be written in any type of programming language, including compiled or interpreted languages, and may be deployed in any form, such as as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a data processing environment. A computer program may be deployed to be executed on one module or on multiple modules that are located at one site or distributed across multiple sites and interconnected by a communication network.

[0195] The method steps of the present invention may be performed by one or more programmable processors executing computer programs to perform the functions of the present invention by operating on input data and generating output. The apparatus of the present invention may be implemented as programmed hardware or as dedicated logic circuitry including Field Programmable Gate Arrays (FPGAs) or Application-Specific Integrated Circuits (ASICs), etc.

[0196] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Typically, a processor receives instructions and data from a read-only memory or a random-access memory or both. The essential elements of a computer are a processor for executing instructions coupled to one or more memories that store instructions and data.

[0197] The above-described embodiments of the invention may be advantageously used independently of any other embodiment or in any feasible combination with one or more other embodiments of the embodiments.

[0198] The following numbered items provide additional information regarding the present invention.

[0199] (Statement 1) A computer-implemented method for detecting relay connections in a network, comprising: receiving, at a server, a perceived indication of the client device; obtaining a geolocation associated with the perceived indication; determining a client-server value based on a transmission time of a connection signal transmitted between the client device and the server; determining an expected value associated with the geolocation; establishing that a connection between the client device and the server is routed through the relayed connection if the client-to-server value exceeds a threshold, the threshold being based at least in part on the expected value; A method comprising:

[0200] (Statement 2) The method described in Statement 1, wherein the connection signal is referred to as a client connection signal, a client-generated signal, and / or a control signal, and / or the perceived indication information is referred to as location indication signaling, location information, and / or information indicating location.

[0201] (Statement 3) The method described in statement 1 or 2, wherein the expected value is an expected round-trip time of a virtual signal transmitted between a virtual device and the server at a geolocation.

[0202] (Statement 4) The method described in Statement 3, wherein the expected value is determined from the geolocation and the propagation speed of the virtual signal.

[0203] (Statement 5) A method according to any of statements 3 and 4, wherein the virtual device is a virtual client device or a virtual probe, and / or the virtual signal is any signal transmitted between the server and the virtual device.

[0204] (Statement 6) A method according to any one of statements 3 to 5, wherein the expected round trip time is the time it takes for the virtual signal to be sent from the server / virtual device to the virtual device / server and for an acknowledgment to be sent back to the server / virtual device.

[0205] (Statement 7) The method described in Statement 1, wherein the expected value is a server-probe value related to the transmission time of a probe signal transmitted between the server and a probe, and the probe is a probe selected from one or more probes that is closest to the geolocation, and / or the one or more probes form a probe network.

[0206] (Statement 8) The method according to any one of statements 1 to 7, wherein the client-server value includes a client-server round trip time of the connection signal.

[0207] (Statement 9) A method according to any one of statements 1 to 8, wherein the client-server value is called a server-client value, and / or the client-server (or server-client) round trip time is the time it takes for a connection signal to be sent from the server / client device to the client device / server and for an acknowledgment of the connection signal to be received by the server / client device.

[0208] (Statement 10) The method described in statements 7 to 9, wherein the expected value includes a server-probe round trip time of a probe signal sent between the server and the probe, preferably the server-probe round trip time is called a probe-server round trip time, and optionally the server-probe round trip time is the time it takes for the probe signal to be sent from the server / probe to the probe / server and for an acknowledgment of the probe signal to be received by the server / probe.

[0209] (Statement 11) A method according to any of statements 1 to 10, wherein the client device is a user equipment (UE), a personal computer, and / or a terminal device, and preferably the client device is connected to the Internet, for example, via an Internet service provider.

[0210] (Statement 12) The method according to any one of statements 1 to 11, wherein the perceived indication information is an Internet Protocol (IP) address, preferably, the perceived indication information is an IPv4 or IPV6 address.

[0211] (Statement 13) The method described in any of statements 1 to 12, wherein the connection signal sent between the client device and the server is at least one of a Transmission Control Protocol (TCP) handshake signal, a Secure Sockets Layer (SSL) handshake signal, and a Transport Layer Security (TLS) handshake signal, and optionally, the connection signal transmits TCP, SSL, and / or TLS data packets.

[0212] (Statement 14) The method described in any of statements 8 to 13, wherein another connection signal is sent, the client-server value is based on a transmission time of the another connection signal, and optionally, the another connection signal is at least one of a TLS handshake signal and an SSL handshake signal.

[0213] (Statement 15) The method described in statement 14, wherein the connection signal is a TCP handshake signal, and the other connection signal is at least one of a TLS handshake signal and an SSL handshake signal.

[0214] (Statement 16) A method according to any one of statements 14 to 15, wherein the client-server value comprises an average round-trip time, preferably the average client-server round-trip time being an average of a client-server round-trip time of the connection signal and another round-trip time of another connection signal, and optionally the client-server value being the longer of the client-server round-trip time and another (client-server) round-trip time.

[0215] (Statement 17) The method described in any of statements 1 to 16, wherein the connection signal is separated into different packets and transmitted separately, preferably the length of the TCP / TLS / SSL handshake is thereby extended, more preferably each packet is transmitted as a separate connection signal.

[0216] (Statement 18) A method as described in any of statements 1 to 17, wherein the client-server value is further associated with a cryptographic signal round-trip time between the server and the client device, and preferably the client-server value is associated with the cryptographic signal in that the cryptographic signal is taken into account in determining the client-server value or is used in the client-server value.

[0217] (Statement 19) The method described in statement 18, wherein the client-server value is calculated from an average including the client-server round trip time and the encrypted signal round trip time, and preferably the client-server value is determined as the longer of the client-server round trip time and the encrypted signal round trip time.

[0218] (Statement 20) A method according to any of statements 18 to 19, wherein during cipher negotiation with the client device, the server is configured to reject a cipher setting proposed by the client device, and optionally the server determines a cipher round-trip time from an additional cipher sent by the client device, preferably the additional cipher being sent using a “ChangeCipherSpec” packet.

[0219] (Statement 21) The method described in any one of statements 7 to 20, wherein the probe signal is an Internet Control Message Protocol (ICMP) Ping, a Transmission Control Protocol (TCP) (handshake) signal, or a Transport Layer Security (TLS) (handshake) signal.

[0220] (Statement 22) A method described in any of statements 7 to 21, wherein the expected server value includes a further server-probe value associated with a second probe, and optionally, multiple probes are used to determine the expected server value, and preferably, the further server-probe value is a further server-probe round-trip time.

[0221] (Statement 23) The threshold is determined using at least the following formula: [LS_RTT+C·LS_RTT]+[(D_cp+GE) / ω] A method according to any of statements 1 to 22, wherein LS_RTT is an expected value, C is a constant preferably between 0 and 1, and / or C is a relative error margin for the detection of LS_RTT, D_cp is the distance between the geolocation associated with the perceived indication information and the probe or the virtual device, GE is the geolocation expected error associated with the determination of the geolocation, and ω is the expected propagation speed of a signal transmitted between the server and the client device.

[0222] (Statement 24) The confidence level associated with the threshold is calculated as follows: Confidence=min((CS_RTT-LS_RTT-[(D_cp+GE) / ω]) / (C·LS_RTT),1), or Confidence=(CS_RTT-LS_RTT-[(D_cp+GE) / ω]) / (C·LS_RTT) The method set forth in statement 23.

[0223] (Statement 25) The method according to any one of statements 1 to 24, wherein the relay connection is a virtual private network connection, a Tor connection, a proxy connection, or a tunneling connection.

[0224] (Statement 26) A computer program product that, when executed on a computer, causes the computer to perform a method for detecting relayed connections in a network, the method comprising: receiving, at a server, a perceived indication of the client device; obtaining a geolocation associated with the perceived indication; determining a client-server value based on a transmission time of a connection signal transmitted between the client device and the server; determining an expected value associated with the geolocation; establishing that a connection between the client device and the server is routed through the relayed connection if the client-to-server value exceeds a threshold, the threshold being based at least in part on the expected value; a computer program comprising:

[0225] (Statement 27) An information device for detecting a relay connection in a network, comprising: a memory; and a processor connected to the memory, the processor: Obtaining a geolocation associated with the perceived indication; determining a client-server value based on a transmission time of a connection signal transmitted between the client device and the server; determining an expected value associated with said geolocation; establishing that a connection between the client device and the server is routed through the relay connection when the client-to-server value exceeds a threshold, the threshold being based at least in part on the expected value; An information processing device configured as follows.

[0226] (Statement 28) A computer program that, when executed by a computer / computing device / teleconferencing device, causes the device to perform the method of any of statements 1 to 25, preferably stored on a computer-readable medium, more preferably the computer-readable medium is non-transitory.

[0227] (Statement 29) A computer program that, when executed by a companion device, causes the companion device to perform any of the methods of statements 1 to 25, preferably the computer program is stored on a computer-readable medium, more preferably the computer-readable medium is non-transitory.

[0228] In addition to the above-described embodiments, the following supplementary notes are also disclosed. (Supplementary Note 1) A computer-implemented method for detecting relay connections in a network, comprising: receiving, at a server, a perceived indication of the client device; obtaining a geolocation associated with the perceived indication; determining a client-server value based on a transmission time of a connection signal transmitted between the client device and the server; determining an expected value associated with the geolocation; establishing that a connection between the client device and the server is routed through the relayed connection if the client-to-server value exceeds a threshold, the threshold being based at least in part on the expected value; A method comprising: (Supplementary Note 2) The method of Supplementary Note 1, wherein the expected value is an expected round-trip time of a virtual signal transmitted between the server and a virtual device at the geolocation, and is determined from the geolocation and a propagation speed of the virtual signal. (Supplementary Note 3) The method described in Supplementary Note 2, wherein the expected value is a server-probe value related to a transmission time of a probe signal transmitted between the server and a probe, and the probe is a probe selected from one or more probes that is closest to the geolocation. (Supplementary Note 4) The method according to any one of Supplementary Notes 1 to 3, wherein the client-server value includes a client-server round trip time of the connection signal. (Supplementary Note 5) The method of Supplementary Note 3, wherein the expected value includes a server-to-probe round trip time of a probe signal transmitted between the server and the probe. (Supplementary Note 6) The method of Supplementary Note 1, wherein the perceived indication information is an Internet Protocol (IP) address. (Appendix 7) The method of Appendix 1, wherein the connection signal transmitted between the client device and the server is at least one of a Transmission Control Protocol (TCP) handshake signal, a Secure Sockets Layer (SSL) handshake signal, and a Transport Layer Security (TLS) handshake signal. (Supplementary Note 8) The method of Supplementary Note 4, wherein another connection signal is transmitted and the client-server value is based on a transmission time of the other connection signal. (Supplementary Note 9) The method according to Supplementary Note 8, wherein the connection signal is a TCP handshake signal, and the other connection signal is at least one of a TLS handshake signal and an SSL handshake signal. (Supplementary Note 10) The method described in Supplementary Note 8, wherein the client-server value includes an average round-trip time, and the average client-server round-trip time is an average of the client-server round-trip time of the connection signal and other round-trip times of the other connection signals. (Supplementary Note 11) The method of Supplementary Note 1, wherein the connection signal is separated into different packets, and the packets are transmitted separately. (Supplementary Note 12) The method of Supplementary Note 10, wherein the client-server value is further associated with a cryptographic signal round-trip time between the server and the client device. (Supplementary Note 13) The method of Supplementary Note 12, wherein the client-server value is calculated from an average including the client-server round trip time and the cryptographic signal round trip time. (Supplementary Note 14) The method of Supplementary Note 12, wherein during cipher negotiation with the client device, the server is configured to reject a cipher setting proposed by the client device and determine a cipher round-trip time from an additional cipher sent by the client device, preferably the additional cipher being sent using a "ChangeCipherSpec" packet. (Supplementary Note 15) The method of Supplementary Note 3, wherein the probe signal is an Internet Control Message Protocol (ICMP) Ping, a Transmission Control Protocol (TCP) handshake, or a Transport Layer Security (TLS) handshake. (Supplementary Note 16) The method described in Supplementary Note 3, wherein the expected value includes a further server-probe value associated with a second probe. (Supplementary Note 17) The threshold is determined using at least the following formula:

number

number

Claims

1. 1. A computer-implemented method for detecting relay connections in a network, comprising: receiving, at a server, a perceived indication of the client device; obtaining a geolocation associated with the perceived indication; determining a client-server value based on a transmission time of a connection signal transmitted between the client device and the server; determining an expected value associated with the geolocation; establishing that a connection between the client device and the server is routed through the relayed connection if the client-server value exceeds a threshold, the threshold being based at least in part on the expected value; A method comprising:

2. The method of claim 1 , wherein the expected value is an expected round trip time of a virtual signal transmitted between the server and a virtual device at the geolocation, and is determined from the geolocation and a propagation speed of the virtual signal.

3. 3. The method of claim 2, wherein the expected value is a server-probe value related to a transmission time of a probe signal transmitted between the server and a probe, the probe being the closest probe to the geolocation selected from one or more probes.

4. The method of any of claims 1 to 3, wherein the client-server value comprises a client-server round trip time of the connection signal.

5. The method of claim 3 , wherein the expected value comprises a server-to-probe round trip time of a probe signal transmitted between the server and the probe.

6. The method of claim 1 , wherein the perceived indicative information is an Internet Protocol (IP) address.

7. 2. The method of claim 1, wherein the connection signals sent between the client device and the server are at least one of Transmission Control Protocol (TCP) handshake signals, Secure Sockets Layer (SSL) handshake signals, and Transport Layer Security (TLS) handshake signals.

8. 5. The method of claim 4, wherein another connection signal is transmitted and the client-server value is based on a transmission time of the other connection signal.

9. 9. The method of claim 8, wherein the connection signal is a TCP handshake signal and the other connection signal is at least one of a TLS handshake signal and an SSL handshake signal.

10. 9. The method of claim 8, wherein the client-server value comprises an average round-trip time, the average client-server round-trip time being an average of the client-server round-trip time of the connection signal and other round-trip times of the other connection signals.

11. The method of claim 1 , wherein the connection signal is separated into different packets, and the packets are transmitted separately.

12. 11. The method of claim 10, wherein the client-server value is further related to a cryptographic signal round trip time between the server and the client device.

13. 13. The method of claim 12, wherein the client-server value is calculated from an average including the client-server round trip time and the cryptographic signal round trip time.

14. 13. The method of claim 12, wherein during cipher negotiation with the client device, the server is configured to reject a cipher setting proposed by the client device and to determine a cipher round-trip time from an additional cipher sent by the client device, preferably the additional cipher being sent using a "ChangeCipherSpec" packet.

15. The method of claim 3 , wherein the probe signal is an Internet Control Message Protocol (ICMP) Ping, a Transmission Control Protocol (TCP) handshake, or a Transport Layer Security (TLS) handshake.

16. The method of claim 3 , wherein the expected value includes an additional server-probe value associated with a second probe.

17. The threshold is determined using at least the following formula: [Equation 1] Here, LS RTT is the expected value, C is a constant preferably between 0 and 1, or C is the LS RTT 4. The method of claim 3, wherein ω is the relative error margin of detection of the perceived indication, D_cp is the distance between the geolocation associated with the perceived indication and the probe or the virtual device, GE is the geolocation expected error associated with the determination of the geolocation, and ω is the expected propagation speed of a signal transmitted between the server and the client device.

18. The confidence level associated with the threshold is calculated as: [Equation 2] 18. The method of claim 17.

19. The method of claim 1 , wherein the relay connection is a virtual private network connection, a Tor connection, a proxy connection, or a tunneling connection.

20. 1. A computer program product that, when executed on a computer, causes the computer to perform a method for detecting relayed connections in a network, the method comprising: obtaining a geolocation associated with the perceived indication; determining a client-server value based on a transmission time of a connection signal transmitted between the client device and the server; determining an expected value associated with the geolocation; establishing that a connection between the client device and the server is routed through the relayed connection if the client-server value exceeds a threshold, the threshold being based at least in part on the expected value; a computer program comprising:

21. 1. An information processing device for detecting a relay connection in a network, comprising: a memory; and a processor connected to the memory, the processor comprising: Obtaining a geolocation associated with the perceived indication; determining a client-server value based on a transmission time of a connection signal transmitted between the client device and the server; determining an expected value associated with said geolocation; establishing that a connection between the client device and the server is routed through the relay connection when the client-server value exceeds a threshold, the threshold being based at least in part on the expected value; An information processing device configured as follows.

Images