Cipher suites and SSL inspection: whose TLS posture are you actually running?

Short answer: A cipher suite is the negotiated set of algorithms two endpoints agree on to encrypt a TLS session. The detail nobody puts in the datasheet is that inspection changes who does the negotiating. When a cloud proxy breaks and inspects your traffic, the cipher suite your users actually get to the internet is the proxy's choice, not your endpoint's. dope.security inspects on the device, so the outbound session is negotiated by the endpoint's own TLS stack and trust store, and your cipher policy stays yours.

Most security teams treat cipher suites as a hardening checkbox. Disable RC4, kill 3DES, prefer AES-GCM and ChaCha20-Poly1305, turn on TLS 1.3, run a scanner, get an A grade, move on. That works for the servers you own.

Outbound is different, and it is where the assumption breaks. Every organization running SSL inspection has inserted a middlebox into a protocol that was explicitly designed to prevent middleboxes. That is a legitimate thing to do. It is also a decision about who negotiates encryption on your behalf, and almost nobody evaluates it that way. If you are picking between platforms, our head-to-head on Zscaler versus Netskope is the practical starting point, because both terminate TLS in their own cloud.

What a cipher suite actually is

A cipher suite is a bundle of algorithm choices agreed during the TLS handshake. In TLS 1.2, a suite name like TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 encodes four decisions: the key exchange (ECDHE), the authentication algorithm (RSA), the bulk cipher and mode (AES-256-GCM), and the hash used for the handshake and key derivation (SHA-384).

TLS 1.3 simplified this. It stripped the key exchange and authentication out of the suite name, leaving only the AEAD cipher and hash, so you get short names like TLS_AES_128_GCM_SHA256. Key exchange moved to a separate negotiation, and every non-forward-secret and legacy option was removed from the protocol entirely. That is why TLS 1.3 has five suites and TLS 1.2 has hundreds.

The negotiation itself is simple. The client sends an ordered list of suites it supports in the ClientHello. The server picks one. In practice the server's preference order usually wins, but the client's list is the hard constraint: the server can only choose from what the client offered.

Hold onto that. The client's offered list is the ceiling on the security of the session. Now ask what happens to that list when a proxy is in the path.

Inspection replaces one session with two

SSL inspection, break and inspect, TLS interception, whatever you call it, works the same way everywhere. The inspecting device terminates the client's TLS session, decrypts, inspects, then opens a second, separate TLS session to the real destination. Two handshakes. Two cipher negotiations.

The session your user's browser sees is negotiated against the inspection point, using a certificate signed by a root you installed. The session that reaches the actual server is negotiated by the inspection point's TLS library, with the inspection point's supported suite list, its curve preferences, its TLS version support, and its trust store deciding whether the server's certificate is acceptable.

Your endpoint's carefully hardened cipher policy governs the first hop. It has no bearing on the second. The second hop is the one that touches the internet.

This is not a scandal, and it is not unique to any vendor. It is arithmetic that follows from the design. But it does mean the honest question is not "do we have good ciphers?" It is "whose TLS stack is representing us to the internet, and how much do we know about it?" Our explainer on on-device TLS inspection covers the mechanics of terminating locally instead.

Why the answer differs between a cloud proxy and an endpoint

With a cloud proxy, the outbound TLS stack is shared, multi-tenant infrastructure that you do not operate, do not version, and cannot inspect. Its cipher list, its supported curves, its TLS 1.3 rollout state and its certificate trust decisions are the vendor's product decisions. When they change, your effective outbound TLS posture changes, and you find out from a release note if you find out at all.

With on-device inspection, the outbound stack is the endpoint you already manage. It patches on your OS cadence, uses the trust store you control through MDM, and its cipher and curve support is a property of a fleet you can inventory. If you have a policy that says no TLS below 1.2 and no non-AEAD ciphers on egress, on-device inspection is the only architecture where that policy is enforced by something you own.

Here is the comparison in the terms that matter, competitor behavior paired with ours:

• Who negotiates with the internet: a cloud proxy negotiates the outbound session from its own PoP infrastructure; dope.security negotiates from the endpoint's own TLS stack.
• Trust store: a cloud proxy validates server certificates against the vendor's trust store on the vendor's schedule; dope.security validates against the device trust store you manage.
• Patch cadence: a proxy's TLS library patches when the vendor ships to their fleet; the device's library patches when you push an OS update.
• Protocol support gaps: Palo Alto documents that Prisma Access Explicit Proxy does not support HTTP/2, strips ALPN and requires mandatory decryption, which means the proxy's protocol constraints become your users' constraints; on-device inspection does not sit in a separate protocol path.
• Cert-pinned applications: Zscaler documents that it cannot inspect cert-pinned Microsoft 365, WebEx and Dropbox traffic, and Cloudflare documents TLS interception breaking git, aws, kubectl, terraform, Docker and the ChatGPT desktop app, which pushes teams toward broad bypass lists; dope.security surfaces SSL errors so admins create narrow, deliberate bypasses in a few clicks instead of guessing.
• Where the plaintext exists: with a cloud proxy the decrypted content exists inside third-party infrastructure; with dope.security it exists only on the device the data already came from.

All three of those vendors publish these limits themselves, which is the point. They are documented product behavior, not accusations. Netskope's NewEdge, Zscaler's ZEN nodes and Prisma Access are competent platforms. The structural fact is simply that inspecting in the cloud means outsourcing your outbound cipher negotiation.

The bypass list is a cipher problem in disguise

Every organization running inspection maintains a list of destinations it does not inspect. Certificate pinning is the usual reason: the application ships the expected public key, sees a different one, and refuses the connection. Dev tooling behaves the same way for the same reason, which is why git, Docker and the cloud CLIs show up on every bypass list in the industry.

The security consequence gets glossed over. A bypassed destination is not just uninspected for content. It is a session your policy has no visibility into at all, negotiated entirely between the endpoint and the server, or in the cloud-proxy case, waved through the PoP with no inspection and no record of what was agreed.

Bypass lists tend to grow, because the cost of a broken app is immediate and visible and the cost of an uninspected destination is deferred and invisible. The narrower the bypass list you can operate with, the smaller that blind spot is. That is a practical argument for putting the decrypt point where the error is diagnosable, on the device, rather than in a PoP where the failure arrives as a ticket. We go deeper on the tradeoffs in on-device versus cloud-proxy SSL inspection.

TLS 1.3, ECH, and why the client list matters more every year

TLS keeps moving in one direction: less metadata in the clear. TLS 1.3 encrypted the certificate exchange. Encrypted Client Hello, now standardized as RFC 9849, encrypts the ClientHello itself, including the server name indication that network-layer filtering has relied on for a decade.

For cipher suite policy this matters in a specific way. As more of the handshake becomes opaque to anything in the network path, the only place with a complete, reliable view of what was negotiated is an endpoint of the session. A network device that cannot see the ClientHello cannot tell you which suites were offered, and increasingly cannot tell you which was chosen. An on-device inspection point is an endpoint of the session by construction, so it always can.

If you are tracking that shift, our write-up on URL filtering versus DNS filtering covers how much visibility the network layer has already lost.

What to actually put in a cipher policy for egress

None of this is an argument against hardening. It is an argument for hardening the right stack. A practical outbound cipher policy looks like this.

Require TLS 1.2 as the floor and prefer 1.3 for outbound sessions, and verify that whatever performs your inspection actually enforces that on the internet-facing hop, not only on the hop facing your users. Ask for the supported suite list of the inspection component in writing. If the answer is a marketing page rather than a list, that is your answer.

Restrict to AEAD ciphers, AES-GCM and ChaCha20-Poly1305, and require forward-secret key exchange. TLS 1.3 gives you this by default, which is the strongest reason to prefer it. Then confirm the trust store used for outbound validation is one you can audit and update.

Finally, treat your bypass list as part of your cipher policy, because it is. Every entry is a session you negotiated no requirements for. Keep it short, keep it dated, and keep it reviewed. Our privacy comparison of on-device and cloud SSL inspection covers who can see the plaintext at each stage.

Where dope.security fits

dope.security runs a lightweight agent, the dope.endpoint, that performs SSL inspection locally as part of our Fly Direct secure web gateway. The decrypt point is the device. The outbound session is opened by the device, so the negotiated cipher suite, the TLS version and the certificate validation are all functions of the endpoint you already patch and manage. Nothing about the session depends on reaching a point of presence.

Because inspection happens where the session starts, the rest of the stack gets the plaintext it needs without a second hop. Dopamine DLP inspects file uploads and AI prompts in motion through zero-retention APIs (US Patent 12,464,023). Cloud Application Control reads and injects the tenant header inside the decrypted session, which is what lets you allow a corporate ChatGPT workspace and block personal logins on the same domain. CASB Neural covers the data at rest side in OneDrive and Google Drive. One console, one agent, no add-on SKU per capability.

A healthcare organization with 34 offices secured 99% of devices in a week and cut web access tickets by 70% in the following 90 days, and Greylock Partners left Cisco Umbrella in 27 days from first proposal to signature, specifically because DNS-only filtering could not see inside HTTPS and the SWG component still backhauled.

Cipher suites are the clearest example of a general rule. Every control you push into the network becomes a control the network operator makes on your behalf. Move the control to the device and the decision comes back to you. Your TLS posture should be a property of your fleet, not of somebody else's data center.

Want to see what your outbound sessions actually negotiate? Book a 20-minute demo and we will show inspection running on the endpoint, with the handshake terminating on the device.

Frequently Asked Questions

What is a cipher suite in simple terms?

A cipher suite is the set of cryptographic algorithms two systems agree on to protect a TLS connection: how they exchange keys, how they authenticate each other, which cipher encrypts the data, and which hash secures the handshake. In TLS 1.2 all four are encoded in the suite name. TLS 1.3 reduced the name to just the AEAD cipher and hash and removed every option that lacked forward secrecy.

Does SSL inspection change which cipher suite my traffic uses?

Yes. Inspection splits one session into two, so there are two separate negotiations. Your endpoint negotiates with the inspection point, and the inspection point negotiates separately with the destination server using its own supported suites and preferences. With a cloud proxy that second negotiation is performed by the vendor's infrastructure. With dope.security it is performed by the device's own TLS stack.

How many cipher suites does TLS 1.3 support?

Five, compared with hundreds in TLS 1.2. TLS 1.3 removed static RSA and Diffie-Hellman key exchange, all non-AEAD ciphers, RC4, 3DES, MD5 and SHA-1 based constructions, and compression. That is why enforcing TLS 1.3 is a faster route to a strong cipher policy than curating a TLS 1.2 list.

Why do cert-pinned applications break under TLS inspection?

A pinned application knows the exact public key or certificate it expects from the server. An inspection point presents a different certificate signed by your internal root, the pin check fails, and the app refuses the connection. Zscaler documents that it cannot inspect cert-pinned Microsoft 365, WebEx and Dropbox traffic, and Cloudflare documents interception breaking git, aws, kubectl, terraform and Docker. dope.security surfaces SSL errors in the console so admins can create narrow bypasses quickly rather than broad ones.

Should I be worried about bypass lists?

Yes, more than about the cipher list itself. A bypassed destination is a session your policy places no requirements on and has no record of. Bypass lists tend to grow because broken applications produce immediate tickets while uninspected destinations produce nothing visible. Keep the list short, dated and reviewed, and prefer an architecture where the failure is diagnosable so bypasses can be narrow.

Does Encrypted Client Hello make cipher suite visibility impossible?

For anything sitting in the network path, largely yes. ECH, standardized as RFC 9849, encrypts the ClientHello including the server name, so a network device can no longer read which suites were offered or which destination was requested. An endpoint of the session still sees everything, which is why on-device inspection retains visibility that DNS resolvers, firewalls and cloud proxies are losing.

Can I set an outbound cipher policy and actually enforce it?

Only if you control the stack that faces the internet. Ask your inspection vendor for the supported suite list, TLS version floor and trust store used on the outbound hop, in writing. With on-device inspection the answer is your own operating system's TLS configuration, which you can audit through MDM and patch on your own cadence.