Man
Professional
- Messages
- 3,051
- Reaction score
- 577
- Points
- 113
I was interested in the technical part of the question: is it possible to somehow determine the use of proxy servers and VPN from the server side, without putting in much effort?
It is possible, under certain conditions. And quite accurately.
When your browser or any other software working with the network creates a TCP connection to a remote server, the Maximum Segment Size (MSS) value is placed in the packet headers, which tells the server what maximum segment size it can transmit in one packet. This value is very close to MTU, it immediately lets the server know about the capabilities of your Internet connection, eliminating unnecessary fragmentation and allowing you to utilize your channel to the fullest.
When you send a packet while connected to a VPN via some protocol (PPTP, L2TP(±IPsec), IPsec IKE), it is placed (encapsulated) into another packet, which introduces its own overhead, and large packets that would be sent without fragmentation without a VPN will now have to be fragmented. To avoid such fragmentation, the OS sets the MTU on the network interface to be smaller than the MTU of the real network interface, which prevents the OS from trying to create large packets that would require fragmentation.
In the case of PPTP, L2TP(±IPsec), IPsec, as I understand it, there are no standards for the tunnel MTU, everyone sets such values so that it works in most cases, and they are set by eye. As a rule, it is 1400, which allows using, say, PPTP on channels with an MTU of up to 1440 without fragmentation (for example, when another tunnel is required to access the Internet, as is often the case with Russian providers). OpenVPN, perhaps the most popular VPN option, on the other hand, took a different route.
Let's look at typical MSS values:
If the cipher is 64 bits, it is probably Blowfish, if 128 - probably AES.
To further test the theory, 2 VPN services were tested: VyprVPN and ibVPN. Both services are susceptible to detection of settings by the described method.
If you do not want to be detected in this way, you can either disable mssfix, setting it to 0 on both the server and clients, thus getting an MSS of 1460 (in case of IPv4), which corresponds to an MTU of 1500 - a typical MTU for a regular wired connection, which the vast majority of users have. However, in this case you will get excessive fragmentation, which leads to increased latency and decreased throughput, so it may make sense to set the MTU to 1400, 1380 or similar (should be a multiple of 2, and preferably 10), since such values are often used by providers, for example, mobile Internet.
It seems to me that proxies are most often launched on Linux and BSD, and are used more often under Windows. Users often do not think about changing the User-Agent, which includes the OS used, in the browser, and this is to our advantage.
From this came ＷＩＴＣＨ？, which will easily tell you about your OpenVPN connection settings (if you haven't touched mssfix, of course), try to detect your OS and compare it with the OS in User-Agent, get the PTR record for your IP and compare it with a set of rules, determining whether you are using an Internet channel designed for home or server users.
ＷＩＴＣＨ？ also detects Tor Browser users without problems, since it uses the same static User-Agent (with Windows) on all OS, and exit nodes are launched under Linux and FreeBSD.
During the tests, many interesting details were revealed:
I don't know what came over me half a year ago, but I decided to rewatch the animated series WITCH, and, not finding a normal release, I bought everything that could be bought, downloaded everything that could be downloaded, and made a release with English, French, Spanish, Dutch, Italian, German, Russian, Norwegian, Danish, Swedish, Finnish, Czech, Turkish, Polish, and Hungarian.
That's how things are.
It is possible, under certain conditions. And quite accurately.
MSS and MTU
MTU, or Maximum Transmission Unit, is the maximum amount of data that can be transmitted in one packet. MTU is set for each network adapter, even for those routers through which traffic from you to a remote server goes in transit. In the vast majority of cases, MTU 1500 is used on the Internet, but there are notable exceptions, which, by the way, often follow some rules.When your browser or any other software working with the network creates a TCP connection to a remote server, the Maximum Segment Size (MSS) value is placed in the packet headers, which tells the server what maximum segment size it can transmit in one packet. This value is very close to MTU, it immediately lets the server know about the capabilities of your Internet connection, eliminating unnecessary fragmentation and allowing you to utilize your channel to the fullest.
When you send a packet while connected to a VPN via some protocol (PPTP, L2TP(±IPsec), IPsec IKE), it is placed (encapsulated) into another packet, which introduces its own overhead, and large packets that would be sent without fragmentation without a VPN will now have to be fragmented. To avoid such fragmentation, the OS sets the MTU on the network interface to be smaller than the MTU of the real network interface, which prevents the OS from trying to create large packets that would require fragmentation.
In the case of PPTP, L2TP(±IPsec), IPsec, as I understand it, there are no standards for the tunnel MTU, everyone sets such values so that it works in most cases, and they are set by eye. As a rule, it is 1400, which allows using, say, PPTP on channels with an MTU of up to 1440 without fragmentation (for example, when another tunnel is required to access the Internet, as is often the case with Russian providers). OpenVPN, perhaps the most popular VPN option, on the other hand, took a different route.
OpenVPN
For compatibility with old or simply buggy software, OpenVPN does not set a smaller MTU value on the VPN interface by default, but changes the MSS value inside the encapsulated TCP packet. The mssfix parameter is responsible for this, set to 1450 by default. It changes the MSS in such a way that it fully utilizes the channel with MTU 1450, i.e. it calculates its overhead costs in such a way that they pass through a channel with MTU 1450 or more without fragmentation. As a result, we have the opportunity not only to identify OpenVPN users with the standard mssfix 1450, but also to identify their connection protocol (IPv4, IPv6), transport layer protocol (TCP, UDP), encryption, compression and MAC parameters, since they introduce their unique overhead costs and are reflected in the MSS.Let's look at typical MSS values:
| Protocol | Block size | MAC | Compression | MSS |
|---|---|---|---|---|
| UDP | 64 | SHA1 | - | 1369 |
| UDP | 64 | SHA1 | + | 1368 |
| TCP | 64 | SHA1 | - | 1367 |
| TCP | 64 | SHA1 | + | 1366 |
| UDP | 128 | SHA1 | - | 1353 |
| UDP | 128 | SHA1 | + | 1352 |
| TCP | 128 | SHA1 | - | 1351 |
| TCP | 128 | SHA1 | + | 1350 |
| UDP | 128 | SHA256 | - | 1341 |
| UDP | 128 | SHA256 | + | 1340 |
| TCP | 128 | SHA256 | - | 1339 |
| TCP | 128 | SHA256 | + | 1338 |
If the cipher is 64 bits, it is probably Blowfish, if 128 - probably AES.
To further test the theory, 2 VPN services were tested: VyprVPN and ibVPN. Both services are susceptible to detection of settings by the described method.
If you do not want to be detected in this way, you can either disable mssfix, setting it to 0 on both the server and clients, thus getting an MSS of 1460 (in case of IPv4), which corresponds to an MTU of 1500 - a typical MTU for a regular wired connection, which the vast majority of users have. However, in this case you will get excessive fragmentation, which leads to increased latency and decreased throughput, so it may make sense to set the MTU to 1400, 1380 or similar (should be a multiple of 2, and preferably 10), since such values are often used by providers, for example, mobile Internet.
Proxy
There are not many ways to detect a proxy server if it does not add any headers (like X-Forwarded-For). What is the technical difference between a proxy and a VPN? In the case of a VPN, the remote server receives from you a packet created by your OS, in an unchanged (usually) form. A proxy, on the contrary, receives only all the information about the remote server (IP, port, other parameters) and data, creating a packet on the proxy side itself, and sends it. Different OS create packets differently, differences can even be found from version to version. We can determine the OS of the packet creator with great accuracy, we are not too interested in the version.It seems to me that proxies are most often launched on Linux and BSD, and are used more often under Windows. Users often do not think about changing the User-Agent, which includes the OS used, in the browser, and this is to our advantage.
p0f
There is a great project p0f that will perfectly fit our needs. Passively listening to traffic, it can determine the OS, MTU and browser, notify about the mismatch of the OS of the packet creator and the OS in the User-Agent. In addition, it has an API. By slightly modifying it, adding MTU export via API and updating signatures, we can detect with some accuracy users of popular VPN protocols, proxy users and those users who forge User-Agent.ＷＩＴＣＨ？
After some thought, I decided to make a small web service to implement my ideas, because for some reason I couldn't find anything similar.From this came ＷＩＴＣＨ？, which will easily tell you about your OpenVPN connection settings (if you haven't touched mssfix, of course), try to detect your OS and compare it with the OS in User-Agent, get the PTR record for your IP and compare it with a set of rules, determining whether you are using an Internet channel designed for home or server users.
Code:
First seen = 2015/07/24 17:19:29
Last update = 2015/07/24 18:39:37
Total flows = 7
Detected OS = Linux 3.11 and newer
HTTP software = Firefox 10.x or newer (ID seems legit)
MTU = 1409
Network link = OpenVPN UDP bs64 SHA1
Language = Russian
Distance = 15
Uptime = 1 days 19 hrs 39 min (modulo 165 days)
PTR test = Probably home user
Fingerprint and OS match. No proxy detected.
OpenVPN detected. Block size is 64 bytes long (probably Blowfish), MAC is SHA1.ＷＩＴＣＨ？ also detects Tor Browser users without problems, since it uses the same static User-Agent (with Windows) on all OS, and exit nodes are launched under Linux and FreeBSD.
During the tests, many interesting details were revealed:
- Beeline's mobile internet passes all connections through a proxy under Linux. This was discovered when a person from Beeline logged in from an iPhone to ＷＩＴＣＨ, and the OS was identified as Linux. It is probably through it that they change HTML tags, add a toolbar with mail.ru search and change the design of websites.
- MTU for mobile devices can be literally anything, but usually ends in 0. The exception is Yota with 1358. It is unclear what this depends on, I suspect that it depends on both the settings on the operator side and the phone module. The same SIM card in different phones uses different MTU.
- The code that handles mssfix in OpenVPN is very slow. If you have networking knowledge, C, the desire and the time, please see if it can be optimized.
I don't know what came over me half a year ago, but I decided to rewatch the animated series WITCH, and, not finding a normal release, I bought everything that could be bought, downloaded everything that could be downloaded, and made a release with English, French, Spanish, Dutch, Italian, German, Russian, Norwegian, Danish, Swedish, Finnish, Czech, Turkish, Polish, and Hungarian.
That's how things are.
