A proxy sits in the middle of your connection by definition. What it can do with that position depends on the traffic.

What a proxy can see

  • Plain HTTP: everything. Headers, cookies, form data and page content, which it can also modify or inject into.
  • HTTPS through a CONNECT tunnel: the hostname and port, the timing and the volume. Not the pages, headers or cookies, because TLS runs end to end between your client and the site and the proxy cannot forge the site's certificate.

That second case is the normal one for commercial proxies, and it is why an honest proxy cannot read your HTTPS traffic.

When it becomes an attack

TLS protection holds only while your client verifies certificates. Two things break it:

  1. Installing a proxy's root certificate. Your client then trusts certificates the proxy forges, and the proxy can decrypt everything. A proxy vendor has no reason to ask for this.
  2. Turning verification off. verify=False in Python requests or curl -k means any machine in the path can impersonate the site.

Both are common shortcuts when a proxy "does not work", and both hand a stranger your traffic. Fix the underlying error instead.

Where MITM is legitimate

Debugging tools such as mitmproxy, Charles and Fiddler are deliberate man-in-the-middle proxies you run on your own machine, with a certificate you install yourself, to inspect your own requests. That is fine because you control both ends.

Common confusion

Free public proxies are the real risk. Many are compromised machines or deliberate traps, and on plain HTTP they can inject scripts or ads. Free proxies covers what can go wrong and how to test one without exposing anything that matters.