What About TLS?

How do you successfully perform a MITM attack against a connection that is encrypted to prevent MITM attacks? Most websites nowadays serve their content using HTTPS, with SSL or TLS encryption, even if that content is not sensitive. HTTPS was explicitly designed to prevent MITM actions. Privoxy cannot break HTTPS in order to look at the contents of the websites the client is visiting and take actions on them, such as modifying harmful JavaScript code before sending it to the client, without generating lots of security warnings in the client's web browser.

It is still possible to use Privoxy and an MITM attack to decrypt the traffic, analyze it, process it, and send it to the client without triggering security warnings. However, the way to achieve this is ugly and requires the collaboration of the client.

The process works as follows: The administrator creates a CA certificate for internal use and installs it in the clients whose connections he intends to make go through the proxy. Then a corresponding private key is installed in the intercepting proxy. When a browser tries to access an HTTPS site and the connection is intercepted, the proxy generates a fake certificate on the fly using the key, which is trusted by the client, and reads the request. Then the proxy fetches the website normally over HTTPS, processes its contents, and sends its output to the client browser using the spoofed connection.

This approach is controversial because it breaks the assumption that TLS connections are not modified by any intermediary on the network. Privoxy does not support this sort of interception out of the box, although there is a lot of demand for it, according to the project mailing list. However, Privoxy can be chained up with an HTTPS interception mechanism such as ProxHTTPSProxy [9].

In normal conditions, Privoxy is only capable of making limited filtering when dealing with HTTPS connections, and only if the client is actively using the proxy instead of being intercepted.

Final Considerations

A proxy service can greatly improve the web browsing experience. However, using a proxy introduces a new set of problems.

The first issue is that, in order to visit a website using Privoxy, the proxy has to download it, process it, possibly rewrite its code, and then send the page to the client once it has been fully processed. Most web browsers are designed to download the components of a website once a user attempts to visit it and start displaying these components as they become available. Privoxy, on the other hand, has to download the whole site and process it, and then send it all at once to the browser. The result is that a site might look unresponsive while it is loading.

The default filters and blocklists included with Privoxy are designed not to break websites. That said, they are not as powerful as browser-based blockers such as uBlock Origin. Custom rules may be added in order to suit your needs, but if you do something wrong, you may end up breaking some websites.

It is usually a good idea to use Privoxy with a caching proxy. A caching proxy is a regular proxy that is able to catch requests and keep local copies of the websites the users visit, so it is not necessary to download them every time a user attempts access them. Squid [10] is probably the best known FOSS caching web proxy.

The steps described in this article for implementing a proxy server that is capable of processing websites that use HTTPS in interception mode require a lot of work, and it is recommended that you complement this setup with DNS blocking.

Privoxy is very configurable and surprisingly powerful. You can even hack Privoxy into removing EU cookie warnings and performing other clever tricks. For more information on Privoxy, see the project documentation [11].