Centralized Solutions to Maintain Anonymity: VPN, SSH, SOCKS

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:

 

• X-Forwarded-For: client1, proxy1, proxy2 …

 

• X-Forwarded-For: 163.49.124.54, 167.43.95.102 …

 

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:

 

• Simple anonymous proxies. These proxies don’t hide the fact of HTTP proxy being used, but they replace the client’s IP address with their own.

 

• High anonymity/elite proxies. Such servers additionally conceal the fact of HTTP proxy usage.

 

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:

 

• SOCKS4. These servers only require that the client (e.g. web browser) provide the IP address of the resource being queried. Therefore, the client needs to retrieve this IP address somehow, and the only way to do it is through a direct DNS query circumventing the proxy. This might entail de-anonymization because the ISP can see DNS queries sent in clear text. This vulnerability is referred to as DNS leak.

 

• SOCKS4a. This is a subtype of SOCKS4. The main difference is that a SOCKS4a server only gets the recipient’s DNS name (rather than the IP address) from the client. This may be necessary if the client cannot determine the recipient’s IP address by the DNS name.

 

• SOCKS5. It’s an extension of SOCKS4 as well. A SOCKS5 server supports UDP, IPv6, authorization, etc. Although SOCKS5 proxies can receive both the IP address and DNS name of the target resource, some applications supporting SOCKS5 can obtain the recipient’s IP address before querying the SOCKS5 proxy, which may also cause a DNS leak.

 

2) SSH

 

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:

 

• In one scenario, the application whose traffic is being tunneled must have HTTP/SOCKS proxy configuration in place to forward the traffic to SSH tunnel over a local proxy server. If there are no such settings, you can use specially crafted programs that route the traffic via a proxy server.

 

• In the other scenario, you can set up an almost fully functional VPN connection and thereby do without SOCKS configuration. From version 4.3 onwards, the popular Secure Shell based suite called OpenSSH can use tunnel-like network interfaces of the 2nd or 3rd layer of the OSI model, that is, create connections resembling VPN ones.

 

Let’s compare VPN and SSH in terms of anonymity

 

Goals

 

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.

 

Security

 

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

 

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.

 

Connection speed

 

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:

 

• Network – 96.5 Mbps

 

• Network/SSH – 94.2 Mbps

 

• Network/VPN – 32.4 Mbps

 

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:

 

• Remove default routes if any.

 

• Allow access to the VPN server’s address only.

 

• Add a route with the VPN server as the default gateway.

 

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.