Lara Fernández Muñiz

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. ✅ HTTPS turns that conversation into a private channel between two parties. And that privacy is enabled by asymmetric cryptography. 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. ✅ That means anyone can encrypt information for you, but only you can decrypt it. TLS: how HTTPS encryption actually works When you access a website, the process usually follows these steps: Your browser connects to the server and receives its certificate, which includes the public key. It checks that the certificate is legitimate and issued by a trusted authority. Using that public key, it generates and encrypts a session key. Only the server can decrypt it using its private key. Once the session key is shared, communication continues securely and quickly using TLS. ✅ This mechanism is designed to prevent anyone intercepting the traffic from being able to read it. Even if they capture all the packets, all they’ll have is a volume of data that’s impossible to decrypt without the server’s private key. 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: Terminate the TLS connection Decrypt the traffic Analyze the now-readable content (HTTP requests, parameters, headers, payloads, etc.) 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. ✅ TLS protects communication from third parties during transit, and the WAF, as the endpoint of that connection, can inspect the cleartext content and enforce security policies before forwarding it to the backend. Together, they strengthen application security. 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 ✅ They’re a silent piece, but absolutely essential for securing any web application.