How to Tell If Your Network Is Decrypting Your HTTPS Traffic

TLS interception is standard on corporate and school networks, and the padlock does not rule it out. How it works, how to detect it, and what it does and does not expose.

There is a widespread assumption that the padlock icon means nobody between you and a website can read what you send. On a home connection that is broadly true. On a corporate, school or guest network it frequently is not — and the padlock looks exactly the same either way.

The technique is called TLS interception, or SSL inspection. It is standard equipment in enterprise networks, it is usually disclosed somewhere in an acceptable-use policy nobody reads, and it is entirely invisible unless you go looking. This article explains how it works, how to detect it, and what it actually exposes.

How can I tell if my network is inspecting HTTPS?

Open any HTTPS site and inspect the certificate issuer. If you see an unexpected corporate name or a security appliance vendor instead of a public certificate authority, your traffic is being intercepted. For a more thorough check — one that catches selective interception a certificate glance can miss — compare the TLS handshake your browser sends against the one that actually reaches the server.

Check this connection now. The SSL proxy check compares the handshake as received against your browser's expected fingerprint. It takes a few seconds and needs nothing installed.

How interception works

Normally, HTTPS gives you an encrypted channel directly to the website. Your browser verifies the site's certificate against a set of trusted certificate authorities, and nothing in between can read the contents.

An intercepting proxy splits that into two separate encrypted connections:

  NORMAL HTTPS — one connection, end to end

    Browser ──────────── TLS ────────────▶  Website


  INTERCEPTED HTTPS — two connections, joined in the middle

    Browser ─── TLS ───▶  Proxy  ─── TLS ───▶  Website
                            │
                       decrypt, inspect,
                         re-encrypt

Both halves are genuinely encrypted, which is why the padlock appears. The difference is that the traffic exists in plaintext at the join, inside the proxy, for as long as it takes to inspect it.

The reason your browser does not object is that whoever manages the device installed the proxy's root certificate into the system trust store. Once that certificate is trusted, any certificate the proxy generates is accepted without complaint. On a managed laptop this is typically done automatically during enrolment.

Does the padlock mean my traffic is private?

No. The padlock means your browser negotiated a valid TLS connection with whatever presented a certificate it was willing to trust. It says nothing about whether that party is the website you asked for.

On a managed device, a corporate root certificate in the trust store lets an inspection proxy mint a certificate for any site on demand. Your browser validates it, finds it trustworthy — because you were told to trust its issuer — and shows the same padlock it would show for a direct connection. Everything works exactly as designed; the design just does not promise what most people assume it promises.

What interception does and does not expose

Worth being precise, because there is a lot of exaggeration on both sides.

What an intercepting proxy can see, for traffic it successfully intercepts: full URLs including query strings, page contents, form submissions, anything typed into a web page, credentials sent over HTTPS, API requests and responses, uploaded and downloaded files.

That qualifier matters. Interception is not automatically total — it covers what the proxy is configured to intercept and technically able to intercept, which is usually most web browsing and often not much else.

What it commonly cannot see: traffic from applications using certificate pinning — most mobile banking apps, some messaging apps — which refuse a substituted certificate and simply fail to connect rather than downgrade. Well-implemented end-to-end encrypted messengers also remain protected, because their encryption sits inside the payload rather than being provided by TLS. Organisations frequently exempt categories such as banking and healthcare from inspection deliberately, for liability reasons.

What is often visible even without interception: the domain you are connecting to, the timing and volume of traffic, and DNS lookups. Historically the destination hostname was readable in plaintext during the TLS handshake, and on most networks it still is. Encrypted DNS and Encrypted Client Hello can close parts of that gap where both ends support them, so it is no longer universal — but the safe assumption on a network you do not control is that someone can determine which sites you visit even when they cannot read what you did there.

The security trade-off nobody mentions: interception is not free. The proxy becomes a single point where an entire organisation's traffic exists in plaintext, and some appliances validate upstream certificates less rigorously than a modern browser does. A poorly configured one can leave users less secure overall, not more.

Detecting it

The quick manual check

Open any HTTPS site, click the padlock, and view the certificate. Look at the issuer.

On an ordinary connection you will see a public certificate authority — Let's Encrypt, DigiCert, Google Trust Services, Sectigo. If instead you see your employer's name, a security vendor such as Zscaler, Palo Alto, Netskope, Blue Coat or Fortinet, or a generic internal-sounding authority, traffic is being intercepted.

An unexpected issuer is conclusive evidence of interception. The absence of one is weaker evidence, because checking a single site cannot rule out selective interception, where a proxy inspects some categories and passes others through untouched. Checking one site tells you about that site.

The technical check

A more thorough method compares the TLS handshake your browser sends against what the server actually receives.

Browsers have distinctive handshake fingerprints. The exact list of cipher suites, the order of TLS extensions, the ALPN values, the supported curves, and the deliberately invalid GREASE values Chrome and Firefox insert to catch broken middleboxes — all of these form a signature specific to a browser and version.

A proxy terminates your connection and makes its own, so the handshake reaching the server is the proxy's signature, not your browser's. Comparing what the server sees against what your browser should have sent detects interception even when the certificate on a given site looks unremarkable.

That is what our SSL proxy check does — it inspects the ClientHello as received and compares it with the expected fingerprint for your browser. The detailed explanation covers what each signal means.

Check DNS separately

Our DNS leak test shows which resolvers actually answer your queries. Seeing an internal corporate resolver, or a security vendor's resolver, is evidence that your DNS queries are handled by that resolver and may be subject to organisational filtering or logging.

It is not, by itself, evidence that HTTPS traffic is being decrypted. These are separate layers, and they are frequently deployed independently — plenty of networks filter DNS without inspecting TLS at all, and the reverse also happens. Treat the two results as answering two different questions, because conflating them will lead you to the wrong conclusion about what your network can actually see.

Is HTTPS inspection bad?

It is a trade-off rather than a verdict, and worth understanding on both sides.

Legitimate reasons organisations do it: scanning for malware in encrypted downloads, data-loss prevention, enforcing acceptable-use policy, detecting exfiltration by compromised machines, and meeting compliance obligations that require inspecting what leaves the network. Without inspection, encryption becomes a blind spot that attackers rely on.

The costs, which are real:

• Plaintext exists at the inspection point, creating a concentrated target that did not previously exist.
• Certificate trust is delegated wholesale to the organisation and whatever appliance it operates.
• Applications using pinning break, sometimes in ways that are hard to diagnose.
• The appliance may validate upstream certificates less carefully than the browsers it replaced, weakening security for everyone behind it.
• Configuration mistakes are easy and their consequences are broad.

Reasonable organisations weigh these and inspect selectively. The point for you as a user is not that inspection is sinister — it is that you should know when it is happening, because it changes what "private" means on that network.

Reading the result

Interception detected on a work device on a work network. Expected, and almost certainly disclosed in your employment terms. Worth knowing rather than worrying about — the practical implication is simply that personal browsing on that device is not private, and you should treat it accordingly.

Interception detected on a personal device on a guest or public network. More questionable. Guest networks that intercept traffic frequently disclose this poorly or not at all. A reasonable moment to stop using that network for anything sensitive.

Interception on a network where nobody should be doing it — a café, a hotel, home broadband. Take this seriously. The mechanism is the same one an on-path attacker would use: interpose a certificate the client trusts, terminate the TLS connection, read the contents. What separates authorised inspection from an attack is whether it was sanctioned and whether you knowingly trust the issuing certificate — not anything technical you can observe in the traffic. If you cannot account for why interception is happening, stop using the network for anything that matters and investigate.

No interception detected. Your TLS connections are reaching their destinations directly. Bear in mind the network may still be able to determine which domains you visit.

What you can and cannot do about it

On a device your employer owns and manages, essentially nothing — and attempting to circumvent monitoring on a corporate device is usually a disciplinary matter regardless of the technical means. The realistic answer is to keep personal activity on personal devices.

On your own device you have options, each with limits worth understanding:

A VPN encrypts traffic between your device and the VPN endpoint, so the local network cannot inspect its contents. It does not make you unobservable — the VPN provider handles your traffic once the tunnel terminates, and on a managed device an endpoint agent can see traffic before it ever enters the tunnel. Many corporate networks also block VPN protocols outright, and some acceptable-use policies prohibit them on guest networks.

Cellular data sidesteps the local network entirely, which is the simplest answer when you just need one private task done.

Encrypted DNS (DoH or DoT) protects your lookups from the local resolver but does nothing about TLS interception, which operates at a different layer. Useful, but not a substitute.

The most useful takeaway is not a countermeasure but an accurate mental model: the padlock proves your connection to the next hop is encrypted, not that the next hop is who you think it is. On any network you do not control, that distinction is worth checking rather than assuming.

Frequently asked questions

Can my employer read my HTTPS traffic?

On a device they manage, generally yes. Enrolment usually installs a corporate root certificate that lets an inspection proxy decrypt, read and re-encrypt your browsing. This is normally disclosed in acceptable-use policy. Applications using certificate pinning, and end-to-end encrypted messengers, typically remain unreadable.

What certificate appears when HTTPS inspection is active?

One issued by the organisation or its security vendor rather than a public authority — commonly names like Zscaler, Palo Alto, Netskope, Fortinet, Blue Coat, or an internal-sounding authority such as "Acme Corp Root CA". Seeing any of these instead of Let's Encrypt or DigiCert means the connection is being intercepted.

Can a VPN prevent HTTPS inspection?

It prevents the local network from inspecting your traffic, because everything is encapsulated before it leaves your device. It does not protect you from the VPN provider, nor from monitoring software running on the device itself, and many managed networks block VPNs entirely.

Does encrypted DNS stop HTTPS inspection?

No. DoH and DoT protect your DNS queries from the local resolver, which is a different layer from TLS. A network can run encrypted DNS and still intercept HTTPS, or intercept DNS and leave HTTPS alone. The two need to be checked separately.

Can HTTPS inspection see my passwords?

For traffic it intercepts, yes — a password submitted through a web form is plaintext at the proxy, exactly like any other form field. This is the main practical reason not to sign into personal accounts on a network or device you do not control.

Why do some apps stop working when inspection is enabled?

Certificate pinning. Applications that pin expect a specific certificate and reject any substitute, so instead of being silently inspected they simply fail to connect. Mobile banking apps are the common example, and organisations often exempt them from inspection for this reason.

Is HTTPS inspection legal?

In workplace contexts it is generally lawful where it is disclosed and applied to company-owned equipment, though the specifics vary considerably by jurisdiction — some require explicit notice or employee consent. Interception you have not agreed to, on a network you did not expect it from, is a different matter entirely.