WAF and HTTPS security: the role of asymmetric encryption

January 19, 2026

When we talk about web security, something curious often happens: we spend a lot of time thinking about complex attacks, bots, payloads or WAF rules... and forget something even more critical.

The protection of the traffic itself.

Because before a WAF analyzes a single request, it has already travelled across the internet. And that journey — long, full of intermediaries, and far from private — is only secure thanks to HTTPS and one key element: asymmetric certificates.

Understanding how it works is easier than it seems, once you see the role each piece plays in secure communication.

Why does traffic need to be encrypted no matter what?

The internet wasn’t designed to be private. Every request you make goes through routers, proxies, providers and many systems you don’t control.

If that traffic were sent in plain text, anyone along the way could see:

  • Credentials
  • Personal data
  • Card numbers
  • Cookies
  • Internal application data

It would be like speaking out loud in a crowded room: anyone could listen in on the conversation.

Asymmetric certificates: two keys, one purpose

The mechanism is based on something very simple:

  • Public key: can be shared with anyone who wants to send information securely. It’s included in the server’s HTTPS certificate.
  • Private key: only the server has it. It is never shared.

The two keys are mathematically related, but not the same.

What is encrypted with one can only be decrypted with the other.

TLS: how HTTPS encryption actually works

When you access a website, the process usually follows these steps:

  1. Your browser connects to the server and receives its certificate, which includes the public key.
  2. It checks that the certificate is legitimate and issued by a trusted authority.
  3. Using that public key, it generates and encrypts a session key.
  4. Only the server can decrypt it using its private key.
  5. Once the session key is shared, communication continues securely and quickly using TLS.

Where does the WAF come in?

In a typical architecture, the WAF is the first point of entry from the internet.

That means the client establishes the TLS connection directly with the WAF, not with the backend server.

The WAF holds the private key, so it can:

  1. Terminate the TLS connection
  2. Decrypt the traffic
  3. Analyze the now-readable content (HTTP requests, parameters, headers, payloads, etc.)
  4. Re-encrypt it towards the application server or forward it internally, depending on the architecture

This is essential for the WAF to inspect and apply security rules to actual content—not to encrypted data.

Moreover, the recommended setup is to perimeter-close to the WAF:

It should be the only component exposed to the internet, and the application server should not accept direct traffic from outside. This ensures that all traffic goes through the WAF and nothing reaches the backend uninspected.

In summary

Asymmetric certificates enable:

  • Traffic to be encrypted end to end
  • No intermediary to read data even if they intercept the communication
  • Only the private key holder to decrypt the content (server or WAF)
  • The private key to remain secret from clients at all times
  • The WAF to inspect actual requests, not encrypted data
  • An architecture that prevents uninspected direct access