HTTPS Protected the Page. It Didn’t Protect the Proxy Password.

There are two separate encryption questions:

1. Does the client establish TLS with the proxy before authenticating?
2. Does the client establish TLS with the destination website through the proxy?

An HTTP proxy can support the second without providing the first. The client sends a CONNECT request, authenticates to the proxy, and then starts website TLS inside the resulting tunnel. Website HTTPS begins after the proxy has already received the authentication information.

HTTP Basic authentication encodes the username and password with Base64. Anyone able to read those bytes can decode them without a secret key. SOCKS5 username/password authentication also provides no encryption by itself; this is explicitly documented in RFC 1929.

A TLS-protected HTTP proxy adds another layer: the client first establishes a verified TLS connection with the proxy, then sends CONNECT and proxy authentication inside it. Website TLS runs inside that connection. curl documents HTTPS-proxy support separately.

This explains a common configuration trap. In Python Requests, a dictionary key named https selects the proxy for HTTPS destinations. It does not turn an http:// proxy value into a TLS-protected proxy connection. Requests’ official proxy documentation describes the mapping and authentication syntax.

Likewise, curl treats a proxy address with no scheme as HTTP by default. An HTTPS destination URL does not change that default. These are established protocol and client behaviors; the contribution here is a dated, reproducible measurement set and a current documentation audit.

We ran an isolated Docker container with networking disabled. Inside it, a small authenticated proxy could connect only to a fixed researcher-controlled HTTPS origin. A raw packet socket captured the client-to-proxy connection before TLS termination. We did not use a decrypting inspection proxy as evidence of plaintext on the wire.

Each trial used a new client process, unique synthetic credentials, and a unique origin request marker. The origin separately logged receipt, and the analysis parsed its echoed response. Proxy and origin had separate certificate authorities. Environment proxy settings and curl startup configuration were neutralized.

The main experiment comprised 12 configurations repeated three times: 36 trials. Eighteen were normal requests and eighteen were deliberate certificate-trust failures. A 12-trial development pilot is excluded.

“Credentials observable” means the exact synthetic password was present in SOCKS authentication or the exact Base64 username/password pair was present in HTTP authentication. It does not mean website passwords or session cookies were exposed.

“Destination hostname observable” is a narrower finding than complete browsing-history visibility. In the plain proxy configurations, the destination appears in CONNECT or SOCKS addressing. Our test did not evaluate encrypted ClientHello, traffic analysis, DNS visibility, or anonymity against the proxy operator.

A bad website certificate did not rescue the proxy password

With a plain HTTP proxy and an untrusted origin certificate, both clients refused the website connection in all six negative-control trials. Nevertheless, the proxy authentication had already crossed the captured connection in all six.

That ordering matters. A certificate error at the destination cannot retroactively protect credentials sent to an earlier intermediary.

With an untrusted proxy certificate, both clients failed before authenticated proxy access. With a trusted TLS proxy but an untrusted origin certificate, they also blocked the website request. Across all eighteen negative controls, no request marker reached the lab origin.

Our Requests fixture used an adapter to configure a separate proxy trust context. This is a controlled separation of trust boundaries, not a claim that every default Requests installation uses our certificate configuration. We never disabled certificate verification.

The dashboard showed one active USA IPv4 endpoint, expiry one week later, and auto-renewal off. Its authentication panel labeled the two documented ports “HTTPS/SOCKS.” We used the HTTP(S) port for HTTP CONNECT and the SOCKS port for SOCKS5 remote-hostname mode.

The capture point was the isolated container’s network interface. This verifies what the client emitted toward that endpoint. It does not establish what a physical Wi-Fi observer or ISP could read if the host wrapped that traffic in a VPN. We left the host VPN state unchanged and did not measure Proton’s tunnel or the path after a VPN exit.

We also attempted one unauthenticated TLS handshake, with normal certificate verification, on the documented HTTP(S) port. The peer closed the connection before TLS was established. We therefore did not obtain a verified TLS-to-proxy connection on that port. We did not scan for alternative ports or establish that every product from this provider lacks TLS-to-proxy support.

Unlike the lab phase, we did not collect independent server-side receipt logs for the live phase. Success here means curl completed a certificate-verified HTTPS exchange and received HTTP 200 with a nonempty response, not independently verified origin attribution or IP-location accuracy.

Six earlier failed attempts resulted from our connection-string parsing error. They are recorded separately and excluded from every result above. No provider conclusion comes from those failures.

We examined ten accessible official pages from nine providers, selecting one actionable authenticated example on each. Rayobyte appears twice because its Python guide and homepage curl example were both included. The sample was chosen during source review; it was not random, ranked by market share, or selected before reading the pages.

All ten selected examples use an explicit HTTP proxy scheme or curl’s implicit HTTP default. This is a description of these examples, not an estimate of industry prevalence, a claim about all examples on each page, or a ranking of provider security.

There is important context within these pages. SOAX also shows TLS-proxy values in generic examples. Infatica discusses TLS-proxy syntax elsewhere. Oxylabs explicitly distinguishes the destination protocol from the proxy type. These details are included in our source-linked coding file; choosing an HTTP example does not prove a provider offers no encrypted alternative.

We downloaded and hashed the source pages on 16 October 2026. The current Rayobyte Python page differed from the older search-engine excerpt, illustrating why the audit follows the fetched page rather than a search snippet. We did not execute provider snippets with purchased credentials or assume that each advertised endpoint would behave like our local fixture.

Ask the provider a specific question: “Does this hostname and port support verified TLS from my client to the proxy, before proxy authentication?” “Supports HTTPS websites” answers a different question.

Where supported, configure the proxy URL with the TLS scheme and use the provider’s documented hostname so certificate verification can succeed. Do not simply change a scheme and suppress the resulting certificate error. Both the proxy and website certificates need appropriate verification.

If TLS-to-proxy is unavailable, a VPN can change what is exposed on the local network. Its protection has its own endpoints: it does not automatically encrypt a plain proxy connection after that traffic leaves the VPN tunnel. That boundary is a protocol explanation, not a measured Proton result from this study.

Use a dedicated research credential and protect packet captures. A PCAP containing proxy authentication should be handled like the credential itself. Our paid-service captures remain private; all downloadable captures use synthetic credentials and the isolated lab.

Also verify that the client actually uses the intended route: our HTTP-client routing experiment found configuration-dependent direct connections. Our consumer reporting portal study examines a separate problem, destination access after proxy selection. The VPN versus proxy guide puts connection encryption and application coverage in context.

The experiment ran with curl 8.14.1, Python 3.12.15, Requests 2.32.3, urllib3 2.3.0, and OpenSSL 3.5.8 in the captured container environment. Three repetitions showed the same outcomes for every configuration. All main capture streams had zero reported TCP reassembly gaps.

The independent analysis re-read the saved PCAPs, checked byte matches, parsed origin echoes, verified source hashes, and validated the certificate controls. A separate private check re-read the six paid captures. Repetition demonstrates consistency under these conditions; it is not statistical evidence about other networks, applications, authentication methods, providers, or future versions.

We tested Basic HTTP authentication and SOCKS5 username/password authentication. We did not test Digest, Kerberos, IP allowlisting, browser behavior, interception products, session hijacking, active adversaries, or the proxy operator’s internal handling. TLS concealing our markers also does not conceal connection timing, sizes, the proxy’s IP, or all possible metadata.

The research data and reproducibility notes include the complete 36-trial lab record, synthetic PCAPs, source snapshots, hashes, documentation coding, redacted live results, and validation outputs. The local-image digest records the exact measured image; the supplied Dockerfile allows a fresh reconstruction whose dependency versions may differ.

The useful distinction is precise: HTTPS to the website and encryption to the proxy are separate properties. A changed IP address and a successful HTTPS response do not establish both.