I've implemented a SOCKS5 proxy library, but I just don't get the point of authenticating (or encrypting) connections, which the RFC (1928) seemed pretty adamant about. Isn't anonymity the whole idea of a proxy?

I also understand that encrypting traffic between the client and server is possible, but that only covers the client-server half of client-server-destination path: isn't that kind of pointless? Shouldn't the encryption (if it's absolutely necessary) run end-to-end instead?

1 Answer 1


This is really two questions, but eh...

What's the point of proxy authentication?

Contrary to what you seem to believe, there are many reasons beyond anonymity to use a proxy (and if you want good anonymity, you should use something like Tor rather than a single proxy). A few of those reasons:

  • Bypassing geographical or IP-based restrictions.
  • Using the proxy as a bridge between the network you're on and one you want to access (for example, getting from an internal corporate or cloud network out to the Internet, or the reverse).
  • Using a proxy for monitoring, logging, or filtering network traffic (for your own security, or for the security/control of a company or other entity that wants to limit what you can access on/from its network).
  • Using a proxy for intercepting or modifying network traffic (for security testing, or for tampering with network traffic).

For many of these purposes, there are good reasons to use authentication. For example, a geo-filtering bypass proxy may be offered as a commercial service, and they want to ensure that only paying users can access the proxies they provide. A corporate proxy wants to ensure that only authorized employees are able to access its network, and possibly also to know which employee is using a particular machine for monitoring and logging purposes. Somebody using a network testing proxy that is opened to other devices on the network may want to make sure that only their own authorized devices can connect to the proxy, rather than allowing arbitrary network users to connect and send requests either directly to the proxy or from their computer.

Additionally, having an open proxy is just risky. For example, suppose somebody used an open proxy that you run to send death threats or upload child porn or something else illegal like that, and it gets traced back to your IP address. That's not a good situation to be in (though I'm not a lawyer and am not sure exactly how much legal jeopardy you might be in there), especially if you don't have any way to demonstrate it was somebody else (such as a proxy's authentication logs).

Shouldn't encryption, if used, be end-to-end?

In general, yes, but that's not always practical and there might be reasons to want to separately encrypt the client-proxy traffic anyway. There's no reason that you can't run end-to-end encrypted traffic, such as HTTPS, through a proxy where your encryption to the proxy is itself encrypted. In fact, if you were using the proxy to conceal your network activity from your ISP or similar, you would absolutely want to do this (otherwise the ISP would be able to see your DNS lookups, the domain names of the sites you wanted to connect to, the amount of network traffic you exchange in each direction with each site and at what times, and so on). Encrypting the connection to the proxy is also obviously helpful any time you want secure authentication, although there are ways to do reasonably-secure authentication over insecure connections (such as SRP).

Also, encrypting the connection only between you (the client) and the proxy is still better than no encryption at all, which would be the case when connecting to a server that doesn't support encryption (such as one that only supports HTTP or FTP, for example). A local network attacker still can't see (or modify) what you're doing (as they could if the proxy connection was unencrypted), even though the proxy server and anybody downstream of it can.

You must log in to answer this question.