Does the proxy provider sniff my traffic?

Technically any main-in-the-middle attacker and proxy provider can see all unencrypted traffic, but it is not that bad.

Summary

In 2024 that not much sense to use plain HTTP, unless you know what you are doing. Use HTTPS for all requests and do not skip SSL server certificate validation. Than you’ll be good with a small exception.

Case

Let's assume the client wants to reach the target document with the URL https://www.cloudflare.com/cdn-cgi/trace via proxy with the next address deadbeef:wifi;us;;;@proxy.soax.com:9000

Using cURL as an HTTP client should look this way

$ curl https://www.cloudflare.com/cdn-cgi/trace \
-x "deadbeef:wifi;us;;;@proxy.soax.com:9000"

Steps

Let's look closely at how the L4 Trasport and L5 Session OSI layers work in an HTTP(HTTP CONNECT) proxy scenario:

1. The client resolves DNS proxy.soax.com into ip_addr, let it be 23.109.113.236
2. The client establishes a TCP connection to ip_addr:23.109.113.236 and port:9000
3. The client sent the first HTTP request with the CONNECT method
4. The proxy server handling the request is doing the following:
   1. Validate the auth header - base64 encoded login + password: deadbeef:wifi;us;;;
   2. Lookup the proper node using Proxy Type and GEO settings wifi;us;;; (it might require a few attempts for the Resi nodes, that’s why latency might differ)
   3. Establishes the TCP connection to the target host www.cloudflare.com and port 443.
   4. Reply to the client with the status code 200 OK in case of success
5. The client receives the proxy server reply with the 200 OK status and realizes that the tunnel is established. Starting from this point all bytes that the client sends to the opened socket will go to the target address through the proxy server w/o any modifications or add-ins from the proxy server side.
6. The client establishes a TLS session with the target server using a TLS handshake. They exchange data regarding supported TLS versions, and cipher suites, clients get server public keys, etc. The proxy server can see all this data as any other MITM(Man-in-the-middle) attacker.
7. Starting from this point for the proxy server as for the MITM attacker there is only random binary data that goes from client to target and back. They can read it and save it but can’t decrepit to see the HTTP protocol requests and responses.

warning

As you can see the only data that can leak(that’s unencrypted) is next:

1. Target resource host and port - www.cloudflare.com:443
2. Youre proxy auth data - deadbeef
3. Youre proxy connection settings - wifi;us;;;

So the attacker migh hijack you proxy account and consume your traffic and know what targets you are scrapping.

tip

If the target and client support TLS 1.3 ECH extension, the Client Hellow might be encrypted, and the middleman won't be able to see SNI(domain name of the target resource). Here is a good article about that and Chrome + FF mentions.

Examples

verbose cURL

$ curl -v https://www.cloudflare.com/cdn-cgi/trace \
-x "deadbeef:wifi;us;;;@proxy.soax.com:9000"
* Host proxy.soax.com:9000 was resolved.
* IPv6: (none)
* IPv4: 23.109.113.236, 23.109.113.228
*   Trying 23.109.113.236:9000...
* Connected to proxy.soax.com (23.109.113.236) port 9000
* CONNECT tunnel: HTTP/1.1 negotiated
* allocate connect buffer
* Proxy auth using Basic with user 'deadbeef'
* Establish HTTP proxy tunnel to www.cloudflare.com:443
> CONNECT www.cloudflare.com:443 HTTP/1.1
> Host: www.cloudflare.com:443
> Proxy-Authorization: Basic bm90LXRoaXMtdGltZTp3aWZpO3VzOzs7
> User-Agent: curl/8.5.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 OK
< Request-Uid: 2cf1ca67-a1b4-fa61-31b8-951554463cca
<
* CONNECT phase completed
* CONNECT tunnel established, response 200
... TLS routain below

verbose Netcat

$ AUTH=`echo -n "deadbeef:wifi;us;;;" | base64`
$ echo -e "CONNECT www.cloudflare.com:443 HTTP/1.0\nHost: www.cloudflare.com:443\nProxy-Authorization: Basic ${AUTH}\n" | nc -v proxy.soax.com 9000
Connection to proxy.soax.com port 9000 [tcp/cslistener] succeeded!
HTTP/1.1 200 OK
Request-Uid: 40314a16-4de4-9a99-e4d1-0c69f89a03c0