Many of you use a VPN or proxy in your daily life. Some people use it constantly, gaining access to resources that are blocked at the state or corporate level. Many people use it occasionally to circumvent geographical restrictions. As you may know, major Internet players in video streaming, music, and game sales have never liked users who easily circumvent geographical restrictions by unblocking content that is not available in their country, or making purchases significantly cheaper. You don't need to go far for examples: Netflix changed its usage agreement to include a VPN blocking clause just 2 months ago; Hulu also committed user blocking, and Steam generally looks suspiciously at non-Russian-speaking users from Russia. Recently, companies have been trying to block not specific users, but the IP addresses of VPN services themselves, creating certain inconveniences for the VPN service itself and its users. It seems that they do not use any special tools, but rather block them selectively and manually. Although I do not support any blocking at all, I was interested in the technical part of the question: is it possible to somehow determine the use of proxy servers and VPNs from the server side, without putting much effort?
You can, under certain conditions. And accurate enough.
When your browser or any other network software 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 the maximum size of segments it can transmit in a single packet. This value is very close to the MTU, it immediately lets the server know about the capabilities of your Internet connection, eliminating unnecessary fragmentation and allowing you to fully utilize your channel.
When you send a packet while connected to a VPN over some protocol (PPTP, L2TP(±IPsec), IPsec IKE), it is placed (encapsulated) in another packet, which introduces its own overhead, and large packets that would have been sent without fragmentation without a VPN will now have to be fragmented. To avoid such fragmentation, the OS sets the network interface's MTU to be less than the real network interface's MTU, so the OS does not attempt 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, this is 1400, which allows you to use, 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 contrary, went the other way.
Let's take a look at typical MSS values:
If a cipher with a block size of 64 bits is used, it is probably Blowfish, if 128, it is probably AES.
To further test the theory, 2 VPN services were tested: VyprVPN and ibVPN. Both services are subject to setting detection using the described method.
If you don't want to be detected in this way, you can either disable mssfix by setting it to 0 on both the server and clients, thus obtaining an MSS of 1460 (in the case of IPv4), which corresponds to an MTU of 1500 — the typical MTU for a normal wired connection, which the vast majority of users have. However, in this case, you will get excessive fragmentation, which leads to increased latency and reduced bandwidth, so it may make sense to set the MTU to 1400, 1380 or similar (it should be a multiple of 2, but preferably 10), since such values are often used by providers, for example, mobile Internet.
It seems to me that proxies are most often run on Linux and BSD, and used more often under Windows. Users often don't think about changing the User-Agent, which includes the OS used, in the browser, and this is good for us.
This results in ＷＩＴＣＨ ？, which will easily tell you about the settings of your OpenVPN connection (if you haven't touched mssfix, of course), try to identify your OS and compare it with the OS in the User-Agent, get a PTR record for your IP and compare it with a set of rules, determining whether you are using you are an internet channel designed for home or server users.
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 any problems, since it uses the same static User-Agent (with Windows) on all OSS, and exit nodes are running under Linux and FreeBSD.
The tests revealed a lot of interesting details:
You can, under certain conditions. And accurate enough.
MSS and MTU
MTU, or Maximum Transmission Unit — the maximum amount of data that can be transmitted in a single packet. The MTU is set for every network adapter, even for routers that transit traffic from you to the remote server. In the vast majority of cases, the Internet uses an MTU of 1500, but there are notable exceptions, which, by the way, often obey some rules.When your browser or any other network software 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 the maximum size of segments it can transmit in a single packet. This value is very close to the MTU, it immediately lets the server know about the capabilities of your Internet connection, eliminating unnecessary fragmentation and allowing you to fully utilize your channel.
When you send a packet while connected to a VPN over some protocol (PPTP, L2TP(±IPsec), IPsec IKE), it is placed (encapsulated) in another packet, which introduces its own overhead, and large packets that would have been sent without fragmentation without a VPN will now have to be fragmented. To avoid such fragmentation, the OS sets the network interface's MTU to be less than the real network interface's MTU, so the OS does not attempt 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, this is 1400, which allows you to use, 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 contrary, went the other way.
OpenVPN
For compatibility with old or just crooked software, OpenVPN does not set a lower MTU value on the VPN interface by default, but changes the MSS value inside the encapsulated TCP packet. The mssfix parameter, which is set to 1450 by default, is responsible for this. It modifies the MSS so that it completely disposes of a channel with an MTU of 1450, i.e. it calculates its overhead so that it passes through a channel with an MTU of 1450 or more without fragmentation. As a result, we can not only identify OpenVPN users with the standard mssfix 1450, but also determine their connection protocol (IPv4, IPv6), transport layer protocol (TCP, UDP), encryption, compression, and MAC parameters, as they contribute their own unique overhead and are reflected in the MSS.Let's take a look at typical MSS values:
| Протокол | Размер блока | MAC | Сжатие | 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 |
To further test the theory, 2 VPN services were tested: VyprVPN and ibVPN. Both services are subject to setting detection using the described method.
If you don't want to be detected in this way, you can either disable mssfix by setting it to 0 on both the server and clients, thus obtaining an MSS of 1460 (in the case of IPv4), which corresponds to an MTU of 1500 — the typical MTU for a normal wired connection, which the vast majority of users have. However, in this case, you will get excessive fragmentation, which leads to increased latency and reduced bandwidth, so it may make sense to set the MTU to 1400, 1380 or similar (it should be a multiple of 2, but preferably 10), since such values are often used by providers, for example, mobile Internet.
Proxy service
There aren't many ways to detect a proxy server if it doesn't 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 the packet that your OS created, in an unchanged (often) form. The proxy, on the other hand, receives only all the information about the remote server (IP, port, other parameters) and data, creating a packet on the proxy's side, and sends it. Different operating systems create packages differently, and you can find differences even from version to version. We can determine the OS of the package creator with great accuracy, but we are not too interested in the version.It seems to me that proxies are most often run on Linux and BSD, and used more often under Windows. Users often don't think about changing the User-Agent, which includes the OS used, in the browser, and this is good for us.
p0f
There is a wonderful project called p0f, which will perfectly fit our needs. By passively listening for traffic, it can detect the OS, MTU, and browser, and notify you of a mismatch between the package creator's OS and the OS in the User-Agent. In addition, it has an API. By slightly modifying it, adding MTU export via the API, and updating the signatures, we can detect users of popular VPN protocols, proxy users, and users who spoof the User-Agent with some accuracy.ＷＩＴＣＨ？
After a little thought, I decided to make a small web service to implement my ideas, because, for some reason, I could not find anything similar.This results in ＷＩＴＣＨ ？, which will easily tell you about the settings of your OpenVPN connection (if you haven't touched mssfix, of course), try to identify your OS and compare it with the OS in the User-Agent, get a PTR record for your IP and compare it with a set of rules, determining whether you are using you are an internet channel designed for home or server users.
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 any problems, since it uses the same static User-Agent (with Windows) on all OSS, and exit nodes are running under Linux and FreeBSD.
The tests revealed a lot of interesting details:
- Beeline mobile Internet passes all connections through a proxy under Linux. This was discovered when a person from Beeline went from iPhone to ＷＩＴＣＨ ？, and the OS was identified as Linux. This is probably how they change HTML tags and add a search toolbar. mail.ru and they change the design of websites.
- The MTU for mobile devices can be literally anything, but, as a rule, ends at 0. The exception is Yota with 1358. What this depends on is not clear, I suspect that it depends on the settings on the operator's side, and on the phone module. The same SIM on different phones uses different MTU's.
- The code that is responsible for mssfix in OpenVPN is very slow. If you have knowledge in networks, C, desire and time, please see if it can be optimized.
