ZScaler - SSL/TLS interception - Network Security and Privacy at the Office

Network Security and Privacy at the Office - All withing reasonable limits please

I have recently started working at a major corporation. The latter is sub-contracting loads of different things; from hiring and employee management (actalent, Allegis Group) to IT security (CrowdStrike, ZScaler). It’s only my second professional interaction with Big Brot …huh, ZScaler. But I really find their methods extreme. I mean, it works. and between CrowdStrike and ZScaler, im sure they avoid shit tons of threats actors and security issues that could be from user errors or a real baddy. Zscaler and CrowdStrike are completely different species in the cybersecurity zoo. Both are “cloud-based security platforms,” but they guard different doors.

Zscaler and CrowdStrike are completely different species in the cybersecurity zoo. Both are “cloud-based security platforms,” but they guard different doors.

1. Zscaler, “The Gatekeeper of the Network”

Zscaler sits between you and the internet. Think of it as a cloud firewall + proxy + filter.

What it does:

• Intercepts and inspects all web and cloud traffic.
• Decrypts HTTPS (SSL inspection) to scan for malware, data exfiltration, or policy violations.
• Blocks websites by category (social media, file sharing, etc.).
• Logs every destination, file download, and connection attempt.
• Optionally, applies Data Loss Prevention (DLP) rules to prevent sensitive info from leaving.

Key point: Zscaler does not live on your machine (mostly). It runs in the network or in the cloud, intercepting your traffic before it leaves the company’s perimeter. It’s about network visibility and control.

You can picture it as:

[Your PC] → Zscaler cloud proxy → Internet

2. CrowdStrike, “The Guardian on the Endpoint”

CrowdStrike, specifically CrowdStrike Falcon, runs on your computer itself. It’s an endpoint protection and threat detection system, a kind of next-generation antivirus with a brain.

What it does:

• Installs a lightweight sensor (background service/driver) on your machine.
• Monitors all processes, file operations, scripts, system calls, and network activity.

• Uses behavioral analysis and AI models to detect:

  • Malware execution
  • Exploits
  • Unauthorized privilege escalation
  • Suspicious PowerShell or memory injections
• Sends telemetry back to the CrowdStrike cloud for analysis.
• Can quarantine or kill processes remotely if a threat is detected.

Key point: CrowdStrike doesn’t watch where you browse, it watches what your system does. It’s there to stop ransomware, lateral movement, and data theft after an attacker has already breached something.

So:

CrowdStrike = “inside the house”
Zscaler = “at the fence”

3. They complement each other

Most enterprises deploy both:

• Zscaler keeps malware and suspicious traffic out of the network.
• CrowdStrike catches anything that manages to sneak onto the machine.

Together, they provide:

• Perimeter security (Zscaler)
• Endpoint detection & response (EDR) (CrowdStrike)

4. Practical implications

If you’re using a company-managed machine:

• Zscaler may decrypt and log all your web sessions (URLs, downloads, uploads).
• CrowdStrike may log every executable launched, every PowerShell command, and some in-memory behavior.
• Both send anonymized (but detailed) telemetry to corporate servers or CrowdStrike’s cloud.

You can verify CrowdStrike’s presence:

• On Windows: open Services → look for CrowdStrike Falcon Sensor.

• Command line:

  sc query csagent
  

  or

  sudo systemctl status falcon-sensor
  

Summary

My REALLY ANNOYING ITCH IN REGARDS TO ZCSALER

I hate ZScaler SSL Inspection. I think it’s really one step too far… but they want to go the easy way, they decrypt all user traffic, throwing privacy in the bin, but its easy to view if there is threats. I get it. But I think there are ways to do it without invading the user pricacy.

Remember when the NSA was working on ways to intercept, archive, consult a netizen digital metadata only with a judge-issued warrant and that the data was encrypted, protected from even the NSA employees ? That was before the patriot act, but then 9/11 happened and we shat all over our privacy rights.

A bit of history: NSA, ThinThread, Trailblazer, 9/11, SARC, Binney, Wiebe and Loomis

Before 9/11, the NSA’s Signals Intelligence (SIGINT) work was supposed to operate under a fairly narrow set of legal guardrails. There were two main constraints:

1. FISA (Foreign Intelligence Surveillance Act, 1978), required the government to get warrants from the secret FISA court for targeted surveillance of U.S. persons.
2. The “Church Committee” reforms (mid-1970s), put a stop to the NSA’s free-for-all domestic spying after the Vietnam and Watergate eras.

Within those bounds, the agency did experiment with systems for retaining metadata, call logs, email routing headers, IP connection records, with the idea that analysts could query it only with judicial authorization. The data was supposed to be encrypted at rest, decrypted only when the FISA court signed off. In theory, that meant it was an archive, not an open window.

Through the 1990s the agency ran a cluster of internal projects under the umbrella of ThinThread, led by a senior crypto-engineer named William Binney, with key technical contributions from Kirk Wiebe and Ed Loomis. They were career mathematicians and software architects inside the Signals Intelligence Automation Research Center (SARC).

Then came September 11 2001. Within weeks, the Patriot Act rewrote much of that landscape.

• Section 215 (“business records”) vastly expanded what could be collected “relevant to an investigation.”
• The NSA’s STELLARWIND and later PRISM programs quietly began bulk collection of telephone and internet metadata without individual warrants.
• Judicial oversight was replaced by programmatic authorization: one blanket warrant could cover millions of records.
• Encryption at rest still existed, but access controls changed; analysts could query far more broadly.

The justification was speed and prevention “connect the dots” but the effect was a shift from targeted surveillance to dragnet collection. By the time whistleblowers like Snowden exposed these programs (2013), the idea that metadata was “harmless” had already proven false: it’s enough to map social networks, habits, and movement with eerie precision.

Congress later dialed some of it back (the USA FREEDOM Act of 2015 ended the bulk phone-metadata program), yet the underlying infrastructure massive storage and automated correlation remains. Private companies now perform a milder, commercial version of it every day.

ThinThread was their attempt to modernize signals-intelligence collection with built-in privacy controls. It used automatic anonymization and encryption on all domestic identifiers; only if a target was approved by the Foreign Intelligence Surveillance Court could the system decrypt the metadata. In other words, it was exactly the kind of design you’re describing: data retained and searchable, but personal details locked behind a warrant key.

After 9/11, NSA leadership scrapped ThinThread in favor of a quickly deployed, warrant-less variant called Trailblazer, which dropped the privacy safeguards. Binney and several colleagues later resigned and became public critics, arguing that the secure version had been both cheaper and constitutional.

Today, corporate tools like Zscaler and CrowdStrike are lineal descendants of those ideas same core logic of “inspect, log, correlate,” but justified under enterprise security rather than national security.

This is a story that still ripples through everything from Zscaler’s architecture to your phone’s “telemetry” settings.

What’s this Itch you are talking about ? SSL Inspection ?

Zscaler’s SSL inspection (sometimes called SSL/TLS interception or HTTPS inspection) is one of its most powerful and controversial features. It’s like a “man-in-the-middle,” but done intentionally for security. Let’s unwrap it piece by piece.

1. The core idea

When your browser connects to https://example.com, normally your computer establishes a direct encrypted TLS tunnel to that server. Zscaler, however, sits between you and the internet. It intercepts all outbound HTTPS traffic by redirecting it through a Zscaler proxy in the cloud.

To still see the data, Zscaler decrypts and re-encrypts it on the fly:

You  < TLS >  Zscaler Proxy  < TLS >  Website

The proxy pretends to be the website to you, and pretends to be you to the website.

2. How it works technically

• Your company installs a Zscaler root certificate on all managed devices.
• When you visit https://7-zip.org, Zscaler dynamically generates a fake certificate for that site, signed by the Zscaler root.
• Your browser trusts it because that root certificate is marked as trusted.
• Zscaler decrypts the traffic, scans it for malware, data leaks, policy violations, then re-encrypts it before sending it onward.

This happens in milliseconds, invisibly unless you look closely at the certificate details in your browser, where the “Issued by” field will show Zscaler Inc instead of the original authority.

3. Why companies use it

• Threat detection: catch malicious payloads hidden in HTTPS traffic.
• Data loss prevention (DLP): block uploads of sensitive data.
• Policy enforcement: prevent access to banned categories (torrents, file sharing, adult content, etc.).
• Visibility: give the security team insight into encrypted traffic patterns.

4. The downsides

• Privacy: Zscaler can see everything passwords, personal email, banking details unless the site uses certificate pinning or another protection.
• Breakage: some apps or sites use certificate pinning (they expect a specific certificate). When Zscaler substitutes its own, those apps detect tampering and fail.
• Security paradox: if Zscaler’s root certificate or infrastructure were ever compromised, the attacker could decrypt all intercepted traffic.
• Performance: decryption/re-encryption at scale adds latency and CPU load.

How to know if your SSL/TLS is unpacked, deciphered ?

To know if you are being big-brothered, that is if ZScaler is decipering your SSL/TLS traffic with a man-in-the-middle attack, check this:

1. Open a browser, here’s lets use MSFT EDGE and go to https://www.github.com
2. Click the padlock icon 🔒 at the left of the address bar.
3. In the small popup, click “Connection is secure” (or similar wording).
4. Then click “Certificate is valid” (or “View certificate”).

This opens the full Windows Certificate Viewer window.

🔍 Inside the Certificate Viewer

Once it’s open, you can:

• See Issued To / Issued By, for example, it might say “Issued by: Zscaler Inc” if your traffic is being inspected.

• Go to the Details tab to see:

  • The Subject (the website)
  • The Issuer (the proxy or CA)
  • The Validity dates
  • The Public Key Algorithm (e.g. RSA, ECDSA)

• Export the certificate if you want to analyze it further:

  • Click Copy to File… → choose .cer → then open it with a tool like certutil or openssl.

🧰 Alternate method (for the nerds)

If you want to dig even deeper using Edge’s developer tools:

1. Press F12 or Ctrl + Shift + I to open DevTools.
2. Go to the Security tab (you may need to click >> to find it).

3. You’ll see a quick summary:

   • “The connection to this site is secure.”
   • The certificate chain (click View certificate here to open the full viewer).

This method works even if the padlock option doesn’t show the “Certificate is valid” link.

If you see “Issued by: Zscaler Inc” or anything other than a major Certificate Authority (like DigiCert, Let’s Encrypt, or Cloudflare), it means your HTTPS traffic is being intercepted and re-signed by Zscaler or another corporate SSL inspection proxy.

In contrast, this is a good certificate direct from Github

Protect Against, Circumvent ? First Speak to IT!

To protect information from Zscaler (or any corporate man-in-the-middle proxy), you need to follow the rules, knowthat its NOT YOUR NETWORK and accept that they can chek everything. But if you really want for example, use your personal emails using the office computer, then there are solutions. I ALWAYS FIRST RECOMMEND TO SPEAK WITH IT it’s your job, it’s important, they can help.

Let’s talk methods, while still using the company machine, you need end-to-end encryption that happens inside the HTTPS channel, or encryption that happens before it ever reaches the network stack Zscaler sees.

Let’s go through the viable approaches, ranked by practicality and realism. Personally, I use Proton Mail, Proton Mail, an encrypted email service based in Switzerland. ProtonMail Bridge is great for their mail service. See below for more on this.

1. Use applications with true end-to-end encryption (E2EE)

Zscaler can intercept HTTPS, but it cannot decrypt application-level encryption where the keys never leave the endpoints. Examples:

• Signal Desktop / ProtonMail Bridge / Tutanota / Threema / Keybase, all encrypt messages before they leave your app. Zscaler only sees meaningless ciphertext.
• ProtonDrive / Tresorit / Sync.com, cloud storage systems that encrypt locally before upload.
• Matrix clients (Element, Cinny), all chat messages are end-to-end encrypted before hitting the network.

In short: if the app advertises end-to-end encryption and the encryption keys live only on your device and the recipient’s, Zscaler can’t read it.

2. Use an encrypted container or vault / Split binaries and convert to Bas64

Anything that stays local or syncs as an encrypted blob can’t be inspected. But it CAN BE BLOCKED. If that’s the case, you can convert a binary blob to a byte array in a Base64 format. Rename the text file as a .cpp and boum you have an undetectable piece of data masquarading as source code.

This repo contains scripts I wrote that changes a given binary file so that it is split in files on a maximum size and with the content being text, that is, converted to Base64.

Other tools:

• VeraCrypt, Cryptomator, or Rclone + crypt remote create encrypted volumes or files that appear random to Zscaler.
• Even if you upload those blobs to GitHub, OneDrive, or email, Zscaler sees only encrypted data.

3. Use a trusted VPN or SSH tunnel

A VPN creates its own encrypted tunnel before the proxy sees the traffic. However many organizations, including those running Zscaler, block or intercept VPN protocols. If it’s allowed, it’s the most direct way to bypass SSL inspection.

• Commercial VPNs (Mullvad, ProtonVPN, IVPN) encrypt all traffic before Zscaler’s HTTPS layer.
• SSH tunnel (ssh -D for SOCKS proxy) can protect selective applications like browsers or terminals. If those ports (1194, 443, 22, etc.) are blocked, this might not work without detection, and circumventing IT policy could be disciplinary. Use only if allowed.

4. Encrypt the content yourself

If you have to send a file or text through a normal browser session, you can encrypt it manually first:

• Age, GPG, OpenSSL, or even 7-Zip AES-256 encryption. Zscaler sees a download/upload, but not the plaintext inside.

Example:

7z a secret.7z confidential.txt -pStrongPassword -mhe=on

Even if intercepted, the payload is unreadable without the password.

What doesn’t help

• Private/incognito browser mode (Zscaler still sees it).
• HTTPS alone (that’s exactly what Zscaler decrypts).
• Browser extensions that claim “secure” browsing but don’t handle their own encryption keys.

Bottom line

Zscaler can see and log anything that leaves your system unencrypted, even if it’s HTTPS.

To keep something private:

Encrypt before it hits the network layer Zscaler controls.

Use end-to-end encrypted apps, encrypted archives, or local vaults. That’s the cleanest, policy-respecting way to keep your personal information unreadable, even on a monitored work network.

Is Gmail Safe ?

No mate

Zscaler decrypts and re-encrypts the traffic using its own certificate (the “Issued by Zscaler Inc” one you saw earlier). Because of that, Zscaler can read the entire decrypted HTTPS stream, including:

• Email body text and HTML
• Attachments
• Metadata like sender/recipient addresses

It can scan this content for malware or data-loss-prevention (DLP) rules before forwarding it to Gmail. So if TI have the SSL inspection turned on for your organization, Gmail read through a browser is fully visible to the Zscaler proxy.

Proton Mail in a browser at work ?

When you go to https://mail.proton.me, here’s the chain of events:

1. Your browser makes an HTTPS request.
2. Zscaler intercepts it, substitutes its own Zscaler certificate, and decrypts the connection.
3. It can now see all the encrypted traffic before it reaches Proton’s servers that includes the web page HTML, scripts, and API calls.

What Zscaler cannot see

Even though Zscaler can read the traffic stream, Proton Mail’s encryption happens inside your browser.

Here’s the key:

• Proton Mail’s web client is a cryptographic app written in JavaScript.
• The emails themselves are encrypted with your keys locally in your browser.
• The actual message bodies are stored encrypted on Proton’s servers.

That means:

• Zscaler can see that you’re visiting Proton Mail, the size of your messages, and metadata like “this user just opened their inbox.”
• But it cannot read the actual contents of your emails or attachments, because they’re decrypted only inside your browser using keys derived from your Proton credentials.

Unless Zscaler modifies or injects the Proton Mail JavaScript (which would be detectable and legally dubious), it doesn’t gain access to the plaintext of your messages.

The subtle risk: trust in the code delivery

There’s one theoretical weak point: Zscaler could alter the delivered JavaScript code of Proton Mail in real time, inserting malicious snippets that capture your decrypted messages or passwords before they’re encrypted. This would require an active attack and is highly unlikely in a legitimate enterprise setup, but in principle, SSL inspection enables that level of access.

The encryption keeps your messages secret; the corporate proxy keeps your browsing session visible.

Practical advice

If you must check persona emails at work:

• avoid GMAIL
• Prefer Proton Mail’s desktop app or ProtonMail Bridge with an email client, those handle encryption locally and are much safer.
• Or use your personal device (not on the corporate Wi-Fi), e.g., tether via your phone.
• If forced to use the web interface on a corporate network, assume the company could theoretically see everything you do except your actual message contents.

See my Proton Mail Bridge Setup Guide for useful info on mail bridge

About Guillaume Plante

A developper with a passion for technology, music, astronomy and art. Coding range: hardware/drivers, security, ai,. c/c++, powershell

Email : guillaumeplante.qc@gmail.com

Website : https://arsscriptum.ddns.net