How Enterprise Proxies Intercept and Re-Sign TLS Traffic

Most people searching for a TLS interception proxy do not need one. The category solves a narrow problem: seeing plaintext content inside HTTPS, on traffic you own, from endpoints you control. If either half of that sentence is missing, no amount of tuning will make the product work for you.

That last row kills more deployments than any technical limitation. Interception needs your private CA in the trust store of every client, and contractor laptops, BYOD phones, IoT devices and vendor appliances are exactly the population where you cannot install anything.

An ordinary forward proxy handling HTTPS uses the CONNECT method. The client asks for a raw pipe to host:443, the proxy opens a TCP socket, answers 200 Connection established, then copies bytes without understanding them, as covered in the HTTP CONNECT method explained. It sees the hostname, the port, the TLS SNI field and byte counts. No paths, no headers, no cookies, no bodies.

An interception proxy refuses to build that pipe. It reads the ClientHello, notes the SNI, then answers the handshake itself instead of forwarding it. From that point there are two independent TLS sessions:

[ client ] --TLS session A--> [ proxy ] --TLS session B--> [ origin ]
              proxy's cert                   real cert
              private CA                     public CA

Between session A and session B the request exists in plaintext inside the proxy's memory. That window is both the entire value proposition and the entire risk profile.

Two consequences follow. First, the client's TLS fingerprint never reaches the origin, because the proxy's own TLS library generates the ClientHello the server sees, so any JA3 or JA4 value you tuned is discarded. See TLS fingerprinting for why that matters. Second, your connection's security becomes the proxy's rather than the origin's: if the proxy accepts a weak cipher or a broken chain upstream, the client cannot tell, because it sees a valid certificate signed by a CA it trusts.

That second point is not theoretical. The NDSS 2017 study The Security Impact of HTTPS Interception by Durumeric and colleagues examined interception middleboxes and client security products, and reported that the great majority degraded connection security, with several introducing severe vulnerabilities of their own. US-CERT published alert TA17-075A on the same theme in March 2017, and the NSA followed with Managing Risk from Transport Layer Security Inspection in November 2019. Start any vendor conversation with those three documents open.

Here is the sequence for a browser fetching https://www.sparkproxy.io/ through an inspecting gateway.

1. The client sends a ClientHello. The SNI extension carries www.sparkproxy.io in plaintext, per RFC 6066 section 3. It is the only name the proxy has before it commits.
2. The proxy decides policy on the SNI alone. Bypass, or intercept. There is no second chance: once it starts answering the handshake, it has to see it through.
3. The proxy opens its own TLS session to the origin. It validates the real certificate against the public root store, negotiates a cipher, and learns the true subject and SAN list.
4. The proxy mints a certificate on the fly. It copies the origin's common name and subject alternative names into a fresh certificate, signs it with the private CA key, and caches the result so the next connection to that host is cheap.
5. The proxy completes the client handshake with that forged leaf and its intermediate chain. The client validates it, finds the private root in its trust store, and shows a padlock.

Step 4 is where implementations differ. A proxy that copies the SAN list faithfully works with multi-domain certificates. One that mints a certificate containing only the SNI name breaks any client revalidating the name against a different Host header. Ask for that behaviour in writing.

Squid calls the feature ssl_bump, with decision states peek, stare, splice and bump: splice hands back to a plain tunnel after reading the hello, bump intercepts. Learn that vocabulary even if you buy commercial, because every vendor implements the same four states under different names.

The certificate authority key is the most dangerous secret in the deployment. Anyone holding it can impersonate every site on the internet to every device in your fleet. Three questions decide whether a deployment is sound.

Where does the key live? A CA key in a hardware security module or a cloud KMS with non-exportable keys is a different risk class from a PEM file on a virtual appliance. Ask, then ask again about the disaster recovery copy.

How is the root distributed? Managed devices get it through group policy, Jamf or Intune. Everything else gets it by hand, which is where the plan falls apart. Servers and containers are the forgotten population: a CI runner pulling from a package registry has a trust store too.

What is the rotation plan? Roots get long lifetimes because reissuing them is painful, so the compromise window is measured in years. A deployment with no tested rotation runbook has decided never to rotate.

One detail is worth knowing before a vendor volunteers it. Browsers deliberately relax two protections for locally installed roots: Chrome enforces neither its built-in certificate pins nor Certificate Transparency for chains terminating in a manually installed root. That exemption is what makes corporate interception work in a browser at all. Applications implementing their own pinning get no such exemption.

Interception is sold in four shapes. What matters to a buyer is where the plaintext appears and who is on the hook when it breaks.

Vendor names appear as examples of each category, not as recommendations, and feature sets change. Check the current documentation of any product you shortlist before committing.

For a lab or a CI pipeline, mitmproxy is genuinely the right answer and costs nothing. For a regulated enterprise with an auditor asking for retained evidence, the real differences are logging, retention and the quality of the bypass feeds. Decryption is a solved problem. Everything around it is not.

This list is the same at every organisation. Print it before the pilot.

The pattern is worth naming. Everything with a trust store separate from the operating system needs separate treatment, and the people who own those runtimes are rarely the people who bought the proxy. Budget that integration work: it is the real cost of the project.

TLS 1.3 (RFC 8446, August 2018) encrypts the server certificate. Under TLS 1.2 a passive observer could read that certificate and filter on the subject name. Under 1.3 it cannot. Interception still works, because a trusted local root defeats verification at any version, but the cheap alternatives got weaker. That is the real reason inspection sales grew: not that 1.3 made interception harder, but that it made not intercepting less useful.

Encrypted Client Hello, still an IETF draft and deployed by Cloudflare with support in current Firefox and Chrome builds, conceals the SNI as well. Where ECH is in play, a proxy has no hostname to make a bypass decision on before the handshake, so policy falls back to destination IP or DNS visibility. If you also run DNS over HTTPS, that fallback disappears too, a knock-on effect covered in how DNS over HTTPS affects proxy traffic.

HTTP/3 over QUIC is the third pressure. QUIC runs on UDP and encrypts its handshake earlier, and most inspection products still deal with it by blocking UDP 443 to force a TCP fallback. Ask a vendor whether they inspect QUIC or block it. Both answers are acceptable. A vague one is not.

Bring this list to the demo. The answers separate products faster than any feature matrix.

The overload question deserves attention. Fail-open means an attacker defeats your inspection by generating load. Fail-closed means a capacity problem becomes a total internet outage. Neither is universally correct, but know which one you bought before finding out empirically.

Throughput collapses under decryption. Datasheets quote a firewall figure and a threat-prevention-with-decryption figure. The second is far lower, and it is usually measured at a large object size that flatters the result. Real traffic is mostly small objects and handshakes, and handshakes are the expensive part.

Latency lands per new connection, not per byte. Interception costs an extra handshake. Connection reuse hides most of it, which is why a browser feels fine on an inspected network while a job opening thousands of short connections does not.

You have created a compliance object. The proxy holds decrypted health, financial and legal traffic in memory and possibly in logs. That is why regulated categories end up on the bypass list, and why privacy regimes treat the plaintext as your processing activity.

Trust becomes centralised. One key compromise equals total impersonation of everything, for everyone in the fleet. That risk shape is unlike any other network product, and it is why the NSA guidance recommends inspecting once at a single controlled point rather than chaining inspecting devices.

These are opposite products that share a word, and buyers who land on an inspection vendor while shopping for scraping infrastructure lose weeks to the confusion.

SparkProxy sits firmly in the second column. Traffic to gateway.sparkproxy.io on port 11000 for HTTP and HTTPS, 11002 for sticky sessions, or 13000 for SOCKS5 is tunnelled and never decrypted, so the certificate your client validates is the origin's own and your chosen TLS stack keeps its fingerprint. Published datacenter plans run from Starter at $75 a month with 100 threads and 5 whitelist slots, through Core at $140 with 250 threads and Boost at $240 with 500 threads, up to Plus at $440 with 1000 threads, all with unlimited bandwidth and 30 days validity across a pool of more than a million IPs in 80 or more countries. If you would rather not manage rotation and rendering yourself, the Scraping API opens with 1,000 free credits and no card, then $49 for 250,000 credits a month at 50 concurrent requests, where a plain fetch costs 1 credit and a JavaScript render costs 5.

If you genuinely need both, buy two products. Running an inspection gateway as your scraping egress gives you the worst of both: collection traffic gets its fingerprint rewritten, and inspection logs fill with machine traffic that buries the human activity you deployed the thing to watch. Hardening notes for running your own forward proxy are in securing proxy servers against SSRF and proxy abuse.

One command answers the question. Look at who signed the certificate you actually received:

openssl s_client -connect www.sparkproxy.io:443 -servername www.sparkproxy.io </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates

If the issuer is a public CA, the connection is untouched. If it is your employer, your antivirus, or a product name you recognise, you are being intercepted. In a browser, click the padlock and read the chain: the root will be a name belonging to no public CA.

For scrapers the tell is easier to miss. Requests succeed, but block rates on protected targets rise for no visible reason, because the ClientHello reaching the origin belongs to the middlebox rather than to your client. If a job that ran clean on one network starts getting challenged on another, check the issuer before rewriting your rotation logic. That gap between tunnelling and terminating is also the core of how proxies and VPNs handle encryption differently.