A group of researchers from the University of Michigan published the results of a study on the ability to identify (VPN Fingerprinting) connections to OpenVPN-based servers when monitoring transit traffic. As a result, we identified three ways to identify the OpenVPN protocol among other network packets that can be used in traffic inspection systems to block OpenVPN-based virtual networks.
Testing of the proposed methods in the network of the Merit Internet service provider, which has more than a million users, showed the ability to identify 85% of OpenVPN sessions with a small level of false positives. For verification, a toolkit was prepared that initially detected OpenVPN traffic in passive mode on the fly, and then makes sure that the result is correct through active server verification. A traffic stream with an interactivity of approximately 20 Gbps was mirrored on the analyzer created by the researchers.
During the experiment, the analyzer was able to successfully identify 1718 out of 2000 test OpenVPN connections established by a fake client that used 40 different standard OpenVPN configurations (the method successfully worked for 39 out of 40 configurations). In addition, during the eight days of the experiment, 3,638 OpenVPN sessions were detected in transit traffic, of which 3,245 were confirmed. It is noted that the upper bound of false positives in the proposed method is three orders of magnitude lower than in previously proposed methods based on the use of machine learning.
Separately, the work of OpenVPN traffic tracking protection methods in commercial services was evaluated: out of 41 tested VPN services that use methods to hide OpenVPN traffic, traffic was identified in 34 cases. Services that could not be detected, in addition to OpenVPN, used additional layers to hide traffic (for example, forwarding OpenVPN traffic through an additional encrypted tunnel). Most of the successfully identified services used traffic distortion using XOR operations, additional layers of obfuscation without proper random addition of traffic, or the presence of non-obfuscated OpenVPN services on the same server.
The identification methods used are based on binding to OpenVPN-specific patterns in unencrypted packet headers, the size of ACK packets, and server responses. In the first case, as an object for identification at the stage of connection negotiation, binding to the "opcode" field in the packet header can be used, which takes a fixed range of values and changes in a certain way depending on the stage of connection establishment. Identification is reduced to identifying a specific sequence of opcode changes in the first N-packets of the stream.
The second method is based on the fact that ACK packets are used in OpenVPN only at the stage of connection negotiation and at the same time have a specific size. Identification is based on the fact that ACK packets of a given size occur only in certain parts of the session (for example, when using OpenVPN, the first ACK packet is usually the third data packet transmitted in the session).
The third method is active verification and is caused by the fact that in response to a connection reset request, the OpenVPN server responds with a specific RESET packet (verification does not work when using the "tls-auth" mode, since the OpenVPN server ignores requests from clients that are not authenticated via TLS).
Testing of the proposed methods in the network of the Merit Internet service provider, which has more than a million users, showed the ability to identify 85% of OpenVPN sessions with a small level of false positives. For verification, a toolkit was prepared that initially detected OpenVPN traffic in passive mode on the fly, and then makes sure that the result is correct through active server verification. A traffic stream with an interactivity of approximately 20 Gbps was mirrored on the analyzer created by the researchers.
During the experiment, the analyzer was able to successfully identify 1718 out of 2000 test OpenVPN connections established by a fake client that used 40 different standard OpenVPN configurations (the method successfully worked for 39 out of 40 configurations). In addition, during the eight days of the experiment, 3,638 OpenVPN sessions were detected in transit traffic, of which 3,245 were confirmed. It is noted that the upper bound of false positives in the proposed method is three orders of magnitude lower than in previously proposed methods based on the use of machine learning.
Separately, the work of OpenVPN traffic tracking protection methods in commercial services was evaluated: out of 41 tested VPN services that use methods to hide OpenVPN traffic, traffic was identified in 34 cases. Services that could not be detected, in addition to OpenVPN, used additional layers to hide traffic (for example, forwarding OpenVPN traffic through an additional encrypted tunnel). Most of the successfully identified services used traffic distortion using XOR operations, additional layers of obfuscation without proper random addition of traffic, or the presence of non-obfuscated OpenVPN services on the same server.
The identification methods used are based on binding to OpenVPN-specific patterns in unencrypted packet headers, the size of ACK packets, and server responses. In the first case, as an object for identification at the stage of connection negotiation, binding to the "opcode" field in the packet header can be used, which takes a fixed range of values and changes in a certain way depending on the stage of connection establishment. Identification is reduced to identifying a specific sequence of opcode changes in the first N-packets of the stream.
The second method is based on the fact that ACK packets are used in OpenVPN only at the stage of connection negotiation and at the same time have a specific size. Identification is based on the fact that ACK packets of a given size occur only in certain parts of the session (for example, when using OpenVPN, the first ACK packet is usually the third data packet transmitted in the session).
The third method is active verification and is caused by the fact that in response to a connection reset request, the OpenVPN server responds with a specific RESET packet (verification does not work when using the "tls-auth" mode, since the OpenVPN server ignores requests from clients that are not authenticated via TLS).
