Zero-Trust at the Edge: Rethinking the eDMZ Perimeter (Part 1)

Alex Au — Mon, 09 Mar 2026 15:58:52 +0000

Evolving the Asymmetric WAF-Pass Architecture for Speed and Scale

A few months ago, cloud security architect Kevin Yu published an excellent article titled 'Designing Asymmetric WAF-Pass JWT Assertion'. He highlighted a massive, often-ignored vulnerability in modern cloud architectures: the reliance on static custom headers (e.g., X-WAF-Checked: true) to verify that traffic hitting an Origin actually passed through the CDN and Web Application Firewall (WAF).

Kevin is absolutely right about the problem. Static headers provide zero cryptographic integrity. They are essentially shared passwords; if they leak, your WAF is permanently bypassed, and your Origin is exposed to the open internet.

To solve this, Kevin proposed an innovative architecture:

Using a Lambda@Edge function to make a synchronous network call to a Regional API Gateway
Triggering a Regional Lambda, which calls AWS KMS to generate an Asymmetric JWT
Passing it all the way back to the Edge to be forwarded to the Origin.

It is a highly secure, effective solution that brilliantly solves 95% of the architectural challenge. But as a Cybersecurity-backgrounded Cloud Platform Engineer who spends my days obsessing over system performance and cloud unit economics, it got me thinking:

What if we could extend this design to 99.9% operational efficiency — maintaining that Zero-Trust perimeter with just a fraction of the latency and cost?

Security at the edge is a delicate balancing act. In this three-part series, we are going to break down the cryptography of the Edge perimeter. I will propose a cloud-native, symmetric alternative that achieves this Zero-Trust pattern entirely at the Edge, open-source a custom benchmarking engine to prove the latency savings mathematically, and dive into the FinOps reality of securing the eDMZ.

The Threat Model of the eDMZ

Before we talk about cryptography, we must define the exact threat model we are solving.

When you place a WAF in front of an Application Load Balancer (ALB), EC2 instance, or custom cloud backend, you are creating an Enterprise DMZ (eDMZ). The Origin backend must have absolute mathematical certainty of two things before accepting a request:

The request definitely passed through CloudFront and AWS WAF.
The routing parameters (URI, Headers) have not been tampered with in transit.

If an attacker discovers your Origin's raw IP address or public DNS, they will attempt to bypass the WAF entirely. We need a way for the Edge to mathematically "sign" the request so the Origin can definitively trust its provenance.

The Cryptography Refresher: Asymmetric vs. Symmetric

Kevin’s architecture relies on Asymmetric Cryptography (RSA/ECDSA) to generate JWTs via AWS KMS.

Asymmetric cryptography is a beautiful mathematical construct, perfect for human identity verification (like OIDC) or highly distributed claims where the verifier cannot be trusted with the signing key. However, for Machine-to-Machine (M2M) perimeter routing inside the same organization, it can be computationally heavy.

For a fast, internal perimeter, Time-Based Symmetric Cryptography (HMAC-SHA256) is an incredibly powerful alternative. This is the exact cryptographic algorithm AWS uses for SigV4 to authenticate billions of internal API requests per second.

🔬 Crypto Deep-Dive: The Math of HMAC-SHA256

When designing secure cloud perimeters, engineers often confuse confidentiality with integrity. We frequently hear acronyms like IND-CPA (Indistinguishability under Chosen Plaintext Attack) or IND-CCA — but those are security models for encryption schemes. In eDMZ routing, we aren't encrypting the HTTP headers; we are authenticating them.

Because HMAC-SHA256 is a Message Authentication Code (MAC) rather than an encryption cipher, the mathematically correct security proof is EUF-CMA (Existential Unforgeability under Chosen Message Attack). In the realm of Authenticated Encryption, this provides the critical INT-CTXT (Integrity of Ciphertext/Tag) guarantee.

What does this mean in plain English? It means that even if a hacker sits on the network and captures 10 million valid HTTP requests passing through your CDN (the "chosen messages"), along with their valid HMAC signatures, the mathematically chaotic avalanche effect of SHA-256 ensures they learn absolutely zero bits of information about your secret key. They cannot reverse-engineer the key, and they cannot forge a valid signature for a slightly modified URI or payload.

Because symmetric math relies on rapid bitwise operations (XOR, AND, bit-shifts) rather than the heavy prime factorization or elliptic curve scalar multiplication used in Asymmetric RSA/ECDSA, this EUF-CMA proof can be calculated by a V8 engine in less than a millisecond.

By taking a highly secure shared 256-bit Symmetric Key and hashing the URI, critical Headers, and a tightly constrained timestamp header (e.g., x-cloud-date), we generate an unforgeable signature. You achieve enterprise-grade cryptographic integrity, but at a fraction of the computational cost.

The Proposed Architecture: CloudFront Functions + KVS

The main friction point in using KMS for Edge validation is state and distance. Making a regional API call from an Edge location natively introduces cross-ocean latency.

Instead of heavy Lambda@Edge functions fetching regional secrets, we can execute this Zero-Trust pattern using CloudFront Functions (CFF) and CloudFront KeyValueStore (KVS).

The Compute: We write the HMAC-SHA256 mathematical signing logic in vanilla JavaScript and execute it directly within the CFF V8 JavaScript Engine isolates.

The Key Rotation: We store the Symmetric Key in CloudFront KVS. KVS allows for instant, global key rotation via API, mimicking the operational security benefits of AWS KMS, but doing so natively at the Edge with sub-millisecond read latency.

So... Why isn't this architecture adopted by Kevin?

I want to be completely transparent: my symmetric CFF solution is not a silver bullet. Engineering is always about risk and balances.

My architecture relies on a few critical assumptions and tradeoffs that security engineers must understand:

1. The Bayes Theorem & Execution Order

In AWS, CloudFront Functions run at the Viewer Request phase (before the WAF). Lambda@Edge can run at the Origin Request phase (after the WAF).

We want to ensure: $Signature)≈1Pr(\text{Passed WAF} | \text{Has Signature}) \approx 1$

Kevin's Architecture (Post-WAF): Because execution is sequential, if the signature exists, the WAF must have already passed. The probability $Signature)=1Pr(\text{Passed WAF} | \text{Has Signature}) = 1$ by definition.

My Architecture (Pre-WAF): Because CFF signs the request "blindly" before inspection, we must apply Bayes' Theorem.

\begin{aligned} &Pr(\text{Passed WAF} | \text{Has Signature}) \newline &= \frac{Pr(\text{Has Signature} | \text{Passed WAF}) \cdot Pr(\text{Passed WAF})}{Pr(\text{Has Signature})} \newline &= Pr(\text{Passed WAF}) \end{aligned}

To maintain Zero-Trust integrity, you must rigorously ensure your WAF processes every signed request.

2. Replay Attacks and Missing Payloads

CloudFront Functions cannot read or hash the request body. This means the payload is unprotected by the signature.

To mitigate this and prevent Replay Attacks, your HMAC-SHA256 signature must be strictly time-bound. A 30-to-60 second TTL on the timestamp header ensures that even if an attacker intercepts a signed header, the window to exploit it is practically closed.

3. Why Kevin's Architecture might be a Better Choice

If your backend APIs involve heavy asynchronous processing that takes 5 to 10 seconds to resolve, latency is not your primary concern. In those scenarios, Kevin’s Asymmetric KMS approach is the better fit. The latency overhead won't be noticed, and asymmetric cryptography executed post-WAF provides stronger isolation without relying on WAF configuration hygiene.

However, if your APIs are

highly latency-sensitive,
read-heavy, or
serving dynamic content,

the unit economics and speed of the CFF pattern are mathematically undeniable.

Coming Up in Part 2: The Benchmarks

Theory is great, but hard data is better. In Part 2 of this series, I am going to open-source a custom-built, TypeScript benchmarking engine.

Most CDN benchmarks are deeply flawed by TCP Keep-Alive hoarding and submarine cable jitter. We are going to parse standard deviations, isolate pure V8 engine compute overhead, and prove exactly how much latency these architectures add.

Spoiler alert: We reduced the latency penalty from ~100ms down to 2.5ms and a substantial price drop.

Stay tuned.

Acknowledgments & Notes

A Special Thanks:

I want to extend a massive thank you to my employer, HKET, and my supervisor, Jack Yeung. Fostering an engineering culture that actively supports open-source benchmarking, technical knowledge sharing, and public writing is rare. Their full backing and encouragement made this research and blog series possible.

Author's Note: The architectural concepts, cryptography math, code, and benchmarking data in this series are 100% my original work. I utilized an LLM strictly as an editorial assistant to help structure and refine the prose of this article.

DEV Community: Alex Au