Tag Archives: proxy

How to achieve anonymity: Proxies and tunnels

Anonymity vs. security

There is a widely extended misconception that cryptographic systems achieve both security and anonymity. However, this is far away from being true. Cryptography has been used in systems which aim is anonymity and security, but the sole fact of using some kind of cryptography guarantees nothing.

When two users, Alice and Bob, establish a communication, they want to achieve security to prevent anyone else from knowing the message they are exchanging. They want anonymity to prevent anyone, outside the conversation or in the conversation, from knowing the identity of the sender of the message.

The general consensus is to think of anonymity as the anonymity of the sender of the message, however far too little attention has been paid to the anonymity of the responder. This might sound absurd because the sender should know the identity of the sender in the first place, but this does not need to be true in all cases, like Peer-to-Peer networks, and responder anonymity is indeed achievable.

Proxies

Proxies were initially developed to solve technical problems when accessing the same resource from different clients and to hide the underlying technology from the clients. Since those days, proxies have evolved and adapt to the Internet providing very different functionality.

One of the most common proxies on the Internet is web-cache proxies. These are putted in place by organizations and Internet Service Providers to save bandwidth by temporarily storing previous requested data.

The client want to access some resource stored in the Target, but instead of connecting directly to the Target, it asks the proxy to connect to the Target for him. The first time the client asks for the resource, the Proxy has to connect to the Target and retrieve it. However, the next requests do not need to be retrieved from the target but from the Proxy, which saves bandwidth assuming that the Client and the Proxy are closer than the Client and the Target.

Despite the simple idea of a cache-proxy, there is research that suggests that this kind of system is not efficient on current networks due to the extensive use of dynamic content (the same resource is different depending on who is asking for it) and the increasingly speed on today’s connections.

Anonymity as a side effect

As show in the previous figure, when the client wants to access the target, he asks the proxy and it is the proxy the one who access the target. This means that the target is never connected by the client but by the proxy, and therefore the identity of the client remains concealed.

Additionally, if two clients, A and B contact the proxy for resource R, the proxy would only retrieve R once, which means that the second client to ask for R will not generate any traffic from the proxy to R.

For anonymity to be achieved in this way, it would be necessary for the proxy to not keep track of any requests, because it has all the information about who access what and when.

Tunneling

Tunneling is a technique in which one communication protocol is wrapped into another. By itself, this technique does not provide either anonymity, security, privacy or anything, it is just a technical option.

The original use of this technique was to use new protocols over systems that only allow certain protocols. The new protocol could be wrapped inside the previous and then sent across the network without the old system noticing it.

Circumventing firewalls

Notwithstanding its power for backwards compatibility, tunneling can be used to circumvent certain types of censorship and security measures like firewalls.

When the client requests a censored resource, the firewall blocks it as expected. However, if the request is tunnelled into an accepted way of communications, the firewall lets that request pass through.

SSH tunnels

SSH stands for Secure SHell and was designed to be a replacement of the out-dated and insecure system for remote login telnet. SSH however superseded the set of functionality originally intended for telnet and is currently used for different purposes beyond remote login. One of these uses is tunnelling.

SSH sessions are protected cryptographically to prevent any observer from knowing the content of the messages being sent or even its type. When a protocol is tunnelled through an SSH session it is indistinguishable from a non-tunnelled SSH session. This behaviour allows circumventing firewalls.

On the figure, the Client wants to access some resource that is blocked by the firewall. However, outside the firewall there are free machines (those that are not under censorship) that can access to that resource.

The client then, establish an SSH connection to a free machine and creates a tunnel. All traffic between the Client and the Free machine is encrypted and the firewall does not know either its content nor its type rather that it is some kind of encrypted communication.