WAF y seguridad HTTPS: el rol del cifrado asimétrico

19 de enero de 2026

Cuando hablamos de seguridad web, suele ocurrir algo curioso: dedicamos mucho tiempo a pensar en ataques complejos, bots, payloads o reglas de un WAF… y nos olvidamos de algo incluso más crítico.

La protección del propio tráfico.

Porque antes de que un WAF analice una sola petición, esta ha tenido que viajar por internet. Y ese camino —que es largo, lleno de intermediarios y nada privado— solo es seguro gracias a HTTPS y a un ingrediente clave: los certificados asimétricos.

Entender cómo funciona es más sencillo de lo que parece, una vez que ves qué papel desempeña cada pieza en la comunicación segura.

¿Por qué el tráfico debe cifrarse sí o sí?

Internet no está pensado para ser privado. Cada petición que haces pasa por routers, proxies, proveedores y un montón de sistemas que no controlas.

Si ese tráfico fuera en texto plano, cualquiera en el camino podría ver:

  • Credenciales
  • Datos personales
  • Números de tarjeta
  • Cookies
  • Información interna de la aplicación

Sería como hablar en voz alta en una sala llena de gente: cualquiera podría escuchar la conversación.

Certificados asimétricos: dos claves, un mismo objetivo

El funcionamiento se basa en algo muy simple:

  • Clave pública: puede repartirse a quien quiera enviar información de forma segura. Va incluido en el certificado HTTPS del servidor.
  • Clave privada: solo la tiene el servidor. No se comparte nunca.

Ambas claves están relacionadas matemáticamente, pero no son iguales.

Lo que cifras con una solo puede descifrarse con la otra.

TLS: cómo funciona realmente el cifrado de HTTPS

Cuando accedes a una web, el proceso suele seguir estos pasos:

  1. Tu navegador se conecta al servidor y recibe su certificado, que incluye la clave pública.
  2. Comprueba que ese certificado es legítimo y emitido por una autoridad confiable.
  3. Con esa clave pública, genera y cifra una clave de sesión.
  4. Solo el servidor puede descifrarla con su clave privada.
  5. Una vez que comparten esa clave de sesión, la comunicación continúa cifrada de forma rápida y segura mediante TLS.

¿Cómo interviene el WAF en este escenario?

En una arquitectura habitual, el WAF es el primer punto de entrada desde internet.

Eso significa que el cliente establece la conexión TLS directamente con el WAF, no con el servidor final.

El WAF tiene la clave privada, por lo que puede:

  1. Terminar la conexión TLS
  2. Descifrar el tráfico
  3. Analizar el contenido ya descifrado (peticiones HTTP, parámetros, cabeceras, payloads, etc.)
  4. Volver a cifrarlo hacia el servidor de aplicación o reenviarlo dentro de la red interna según la arquitectura

Esto es fundamental para que el WAF pueda inspeccionar y aplicar reglas de seguridad sobre contenido real, no sobre datos cifrados.

Además, lo recomendable es cerrar perimetralmente al WAF:

Que sea el único elemento expuesto a internet y que el servidor de aplicación no acepte tráfico directo desde fuera. Así te aseguras de que todo el tráfico pase por el WAF y que nada llegue sin ser inspeccionado.

En resumen

Los certificados asimétricos permiten que:

  • El tráfico viaje cifrado de extremo a extremo
  • Ningún intermediario pueda leer datos aunque intercepte la comunicación
  • Solo quien tenga la clave privada pueda descifrarlo (servidor o WAF)
  • La clave privada nunca se comparta con clientes
  • El WAF pueda inspeccionar peticiones reales, no datos cifrados
  • La arquitectura pueda cerrarse para evitar accesos directos no analizados