A Michigan State University research group published findings on the ability to identify (VPN Fingerprinting) connections to OpenVPN-based servers while monitoring transit traffic. As a result, three methods for identifying the OpenVPN protocol among other network packets were revealed, which can be utilized in traffic inspection systems to block virtual networks based on OpenVPN.
Testing the proposed methods in the network of the Merit Internet provider, which has over a million users, demonstrated the ability to identify 85% of OpenVPN sessions with a low level of false positives. A toolkit was prepared for verification, initially passively identifying OpenVPN traffic in real time, then confirming the results through active server verification. The traffic stream was mirrored onto the analyzer created by the researchers, with an intensity of approximately 20 Gbps.

During the experiment, the analyzer successfully identified 1718 out of 2000 test OpenVPN connections established by a dummy client, using 40 different standard OpenVPN configurations (the method successfully worked for 39 out of 40 configurations). Additionally, over the eight days of the experiment, 3638 OpenVPN sessions were detected in the transit traffic, of which 3245 sessions were verified. It is noted that the upper limit of false positives in the proposed method is three orders of magnitude lower than in previously suggested methods based on machine learning.
The effectiveness of methods to protect against OpenVPN traffic tracking in commercial services was assessed separately — of the 41 tested services that used methods to conceal OpenVPN traffic, identification was successful in 34 cases. The services that could not be detected used additional layers to hide traffic (for instance, routing OpenVPN traffic through an extra encrypted tunnel) alongside OpenVPN. Most of the successfully identified services employed traffic distortion using XOR operations, additional obfuscation layers without sufficient random traffic padding, or had unobfuscated OpenVPN services on the same. VPNservice, which made it possible to identify the traffic in 34 cases. The services that could not be detected used additional layers to hide traffic (for example, routing OpenVPN traffic through an extra encrypted tunnel). Most of the successfully identified services employed traffic distortion using XOR operations, additional obfuscation layers without sufficient random traffic padding, or had unobfuscated OpenVPN services on the same. szerveren.
Az alkalmazott azonosítási módszerek az OpenVPN-specifikus sablonokhoz kötődnek a titkosítatlan csomag fejlécében, az ACK-csomagok méretéhez és a szerver válaszaihoz. Az első esetben az azonosítási objektum a kapcsolat létrehozásának fázisában a csomagfejléc "opcode" mezőjéhez való kötődést használja, amely meghatározott értéktartománnyal rendelkezik, és a kapcsolat létesítésének szakaszától függően változik. Az azonosítás célja egy adott opcode-változás sorozatának azonosítása az első N csomagban a forgalomban.
A második módszer azon alapul, hogy az ACK-csomagok csak a kapcsolat létrehozásának fázisában alkalmazhatók az OpenVPN-ben, és ezeknek specifikus méretük van. Az azonosítás azon a tényen alapul, hogy a megadott méretű ACK-csomagok csak a munkamenet bizonyos részein fordulnak elő (például OpenVPN használatakor az első ACK-csomag általában a harmadik csomag, amely adatokat tartalmaz a munkamenet során).

A harmadik módszer aktív ellenőrzés, amely abból adódik, hogy az OpenVPN szerver a kapcsolat visszaállítására irányuló kérelemre egy adott RST-csomagot küld (ez az ellenőrzés nem működik a "tls-auth" üzemmódban, mivel az OpenVPN-szerver ebben az esetben figyelmen kívül hagyja a nem TLS által hitelesített kliensektől érkező kéréseket).

Forrás: opennet.ru
