To begin with, I’d like to point out the fundamental thing: centralized tools cannot ensure a high degree of anonymity, because you still have to trust the central node. I’m not going to dwell on the organizational, political and bureaucratic obstacles to breaking online anonymity.
Perhaps, a VPN server based in Panama is actually more secure than an identical server located in Spain. Maybe not.
I won’t discuss chains of nodes either, because their reliability is very difficult to assess. On the one hand, the organizational hurdles reduce the risk of exposure. On the other hand, though, you need to be confident of every single node’s dependability. Now, let’s move on to the specifics.
1) Proxy servers: HTTP and SOCKS
Let’s take a dive into HTTP headers in HTTP proxies.
The HTTP header is a string in an HTTP message containing certain parameters in the following format: “Name: Value”. There are numerous types of headers that are exchanged between clients and servers as the latter interact.
For example, the line “Date: Mon, 11 Mar 2019 16:21:55 GMT” returns the current date and time from the server to the client.
One of these headers, X-Forwarded-For, is essentially a standard string that allows the server to get the client’s original IP address in scenarios where the server is being accessed over HTTP proxy. Unless filtered, this header renders the whole chain of proxy servers – for instance:
Other headers that disclose de-anonymizing information include HTTP_VIA, HTTP_FORWARDED, etc.
HTTP proxy servers that conceal the client’s IP address are called anonymous proxy servers. There are several different types of them. The breakdown is fairly conditional, and yet it does exist:
As you might know, SOCKS proxies don’t render any headers at all. Let’s look into the difference between SOCKS 4, 4a and 5. There are different SOCKS versions out there:
SSH tunnel is a secure tunnel created by means of SSH connection and used to encrypt data as it’s being transferred. According to Wikipedia, SSH (Secure Shell) is a “cryptographic network protocol for operating network services securely over an unsecured network”.
When an SSH tunnel is used, any protocol’s unsecured traffic is encrypted on one end of SSH connection (client) and decrypted on the other end (SSH server).
The SSH protocol supports several scenarios:
Let’s compare VPN and SSH in terms of anonymity
VPN and SSH were originally designed for different purposes, which explains their pros and cons.
VPN is intended to provide secure remote access to an enterprise network’s resources. As soon as a computer is connected to a VPN server, it becomes a part of the “local” network and can, therefore, use all of its services, including shared resources, local VoIP service, NetBIOS and UDP broadcast queries, common VPN policies, etc. The traffic emanating from the whole operating system and applications is sent over VPN in most cases.
SSH was originally meant to secure remote device management. The SSH connection is a connection established with a specific device rather than with a network. SSH gurus can do a lot of cool things with it, though.
The VPN and SSH protocols are quite secure, except perhaps some PPTP (Point-to-Point Tunneling Protocol) use cases. Most of the possible attacks boil down to man-in-the-middle (MITM) and replacing keys or certificates, although that’s primarily an authentication and user prudence issue.
Usability is a somewhat vague and variable thing that depends on your objectives and skills. It’s easy to connect to a VPN server, but configuring it might be a challenge for inexperienced users. An SSH server is easier to customize, but some people might find it tedious to configure the SSH tunnel for every application manually.
The speed depends on the specific implementation and the protocols being used. Based on my experience, here are the approximate numbers for SSH and OpenVPN:
In summary, it’s worth mentioning that VPN servers are more popular than SSH ones. There are plenty of commercial VPN service providers out there to choose from. Meanwhile, numerous SSH tunnels are also successfully sold on dedicated forums. It’s up to you which one to leverage on your server.
Tip of the day
You might run into a situation where the VPN connection is interrupted for whatever reason. Whereas all network interaction will discontinue if you use a proxy server, in the case of VPN the traffic will still be transmitted in an insecure form.
Commercial VPN providers equip their products with kill switches.
If the custom setup is available, the most reliable option is to use a routing table, where only the VPN server’s gateway is defined as the main one by default. Doing it is a no-brainer:
One more workaround is to enter an inexistent DNS server (for example, 127.0.0.1) in the properties of open Internet connection. In this case, web surfing and suchlike activities become impossible without connecting to the VPN server.
There are also special tools, such as VPN Watcher, that check VPN connection status for predefined applications several times a second and suspend their work if the VPN connection drops.
Configuring the firewall is yet another method to stay safe when a VPN connection is suddenly terminated. The native Windows firewall can do the trick, too.
You can also delimit two types of Internet sessions – secured and unsecured. Just add the session leader to cgroups, from which a non-VPN interface is simply inaccessible. In this case, the data will only be transmitted over this interface.