Skip to content

why-zerotrust-over-https.md

Latest commit

 

History

History
66 lines (49 loc) · 3.39 KB

why-zerotrust-over-https.md

File metadata and controls

66 lines (49 loc) · 3.39 KB
Raw

Why Zero Trust Guard when you already have HTTPS?

This is the question the React + Express demo answers live. Short version:

HTTPS makes the channel private and authenticates the server. Zero Trust Guard authenticates the client, authorizes the request, and enforces those decisions on every request.

They solve different problems. HTTPS alone leaves the classic hole: it never answers "who is on the other side of this encrypted connection?"

What HTTPS actually gives you

  1. Confidentiality — bytes are encrypted in transit; no one on the wire can read them.
  2. Server authentication — the certificate proves you reached the site you meant to reach.
  3. Integrity — tampered bytes fail the TLS handshake/record checks.

HTTPS is a property of the connection (host A ↔ host B), not of the request (who made it).

What HTTPS cannot give you

Question HTTPS cannot answer How Zero Trust Guard answers it
Who is sending this request? Signed access token the gateway verifies on arrival.
Is this user still allowed? Server-side session check — a fired or suspended user is rejected instantly, not at token expiry.
Is this device still trusted? Device record checked against the session; revoke the device, access stops.
May this user call this route/method? Policy engine: roles, deny rules, per-route limits.
Is this a brute-force attempt? Per-IP login limiting + audit events.
Has this token been revoked? Session revocation is immediate, even though the JWT is still cryptographically valid.
Who/what to trust after the proxy? Gateway injects x-ztg-verified, user, session, device, request id; the upstream re-verifies them.

The demo shows the difference (not just says it)

In demo-react:

  1. Call with a valid token → gateway verifies → Express returns the secret plus the x-ztg-* identity the gateway injected.
  2. Call with no token / a forged token → 401 before the request ever reaches Express.
  3. “Revoke this session” → an admin revokes the live session; the very next request with the same, still-valid (HTTPS, unexpired) token returns 401. No TLS feature can do that.
  4. “HTTPS is enough” insecure route (/demo/insecure) → Express deliberately trusts the connection and returns the secret to anyone holding any valid token — and, if the port is reachable, to curl http://localhost:4000/demo/insecure with no token at all.

The last one is the cautionary tale: even behind a gateway, the upstream must check the gateway's headers. The demo's protected /demo/secret does; the insecure route doesn't.

Diagram

HTTPS alone:
  attacker ──(encrypted, server-authenticated)──▶ Express ──▶ serves the secret
  ^ nobody asked who attacker is

HTTPS + Zero Trust Guard:
  attacker ── encrypted ──▶ GATEWAY: no valid token/session/device/role ──▶ 401, never forwarded
  employee  ── encrypted ──▶ GATEWAY: verified → x-ztg-verified: true ──▶ Express: checks header ──▶ data

Good mental model

  • HTTPS = who you're talking to. (the server, privately)
  • Zero Trust Guard = who is talking to you. (the client, authoritatively)
  • One is about the road, the other about who's on the road and whether they still have a ticket.