Modos SSL/TLS de Cloudflare: por qué Full (strict) supera a Flexible y cómo proteger su origen
¿Off, Flexible, Full o Full (strict)? Qué hace realmente cada modo de cifrado de Cloudflare, por qué Flexible es riesgoso y los ajustes que impiden rodear Cloudflare.
Si su sitio web funciona detrás de Cloudflare, el modo de cifrado SSL/TLS determina si la conexión entre Cloudflare y su servidor está cifrada y verificada. Para casi cualquier sitio empresarial la respuesta correcta es Full (strict): instale un certificado válido en su servidor (uno público como Let's Encrypt o AutoSSL, o un certificado gratuito de Cloudflare Origin CA) y deje que Cloudflare lo verifique. Flexible parece cómodo, pero deja sin cifrar la segunda mitad de la conexión y es la causa más común de los errores de "demasiadas redirecciones". Esta guía explica cada modo, los ajustes que lo acompañan y cómo impedir que un atacante rodee Cloudflare para llegar directamente a su servidor.
Dos conexiones, no una
Cuando un visitante abre su sitio web con proxy, existen dos conexiones separadas:
- Del visitante a Cloudflare. Aquí Cloudflare presenta su propio certificado perimetral, y por eso aparece el candado aunque su servidor no tenga ningún certificado.
- De Cloudflare a su servidor (el origen). El modo de cifrado controla esta conexión.
El candado del navegador solo le informa al visitante sobre la primera conexión. La segunda es responsabilidad suya.
Los modos de cifrado, explicados
El modo se elige en la página SSL/TLS > Overview del panel de Cloudflare. También puede definirse por nombre de host con una Configuration Rule.
| Modo | De Cloudflare al origen | ¿Se verifica el certificado? | Cuándo usarlo |
|---|---|---|---|
| Off | HTTP sin cifrar | No | Nunca en un sitio empresarial |
| Flexible | HTTP sin cifrar | No | Solo de forma temporal, mientras el origen obtiene un certificado |
| Full | HTTPS si el visitante usó HTTPS | No | El origen tiene un certificado autofirmado o vencido (temporal) |
| Full (strict) | HTTPS si el visitante usó HTTPS | Sí | La configuración recomendada |
| Strict (SSL-Only Origin Pull) | Siempre HTTPS | Sí | Quiere HTTPS hacia el origen incluso para visitantes por HTTP |
Cloudflare también ofrece la opción Automatic SSL/TLS. Su SSL/TLS Recommender analiza su origen y pasa la zona al modo más seguro que el origen admite, y Cloudflare asegura que nunca bajará su configuración a un modo menos seguro. Es útil, pero igual recomendamos confirmar el modo a mano después de cualquier cambio de servidor o de certificado.
Por qué Flexible es un problema
Con Flexible, Cloudflare se conecta a su servidor por HTTP sin cifrar. Fallan dos cosas:
- El tráfico viaja sin cifrar entre Cloudflare y su servidor. Inicios de sesión, formularios y datos de clientes pasan en texto claro en ese tramo, mientras los visitantes ven un candado y creen que todo está protegido.
- Bucles de redirección. La mayoría de los sitios modernos (WordPress, hosting cPanel con HTTPS forzado y casi todos los frameworks) redirigen HTTP a HTTPS. Cloudflare envía una petición HTTP, su servidor la redirige a HTTPS, Cloudflare vuelve a enviar HTTP y el navegador termina mostrando
ERR_TOO_MANY_REDIRECTS. La propia guía de solución de problemas de Cloudflare señala esta causa.
La solución es instalar un certificado en el origen y pasar a Full (strict), no quitar la redirección a HTTPS del servidor.
Full frente a Full (strict)
Full cifra la conexión pero no verifica el certificado del origen, así que aceptaría un certificado presentado por cualquiera que esté en el camino. Úselo solo como paso temporal mientras corrige un certificado vencido o autofirmado. Full (strict) comprueba que el certificado sea válido y coincida con el nombre de host. Cloudflare acepta un certificado de confianza pública o un certificado de Cloudflare Origin CA.
Certificados Origin CA frente a certificados públicos
| Certificado público (Let's Encrypt, AutoSSL, CA comercial) | Certificado de Cloudflare Origin CA | |
|---|---|---|
| Confiable para los navegadores | Sí | No, solo para Cloudflare |
| Funciona con Full (strict) | Sí | Sí |
| Funciona si pausa Cloudflare o pone un registro en solo DNS | Sí | No, los visitantes ven advertencias de certificado |
| Renovación | Normalmente automática con su hosting o Certbot | Usted elige el período de validez al crearlo |
| Avisos de vencimiento | Depende de su hosting | Cloudflare no envía avisos de vencimiento |
Un certificado Origin CA se crea desde SSL/TLS > Origin Server con Create Certificate. Guarde la clave privada de inmediato, porque se muestra una sola vez. Los certificados Origin CA no pueden incluir direcciones IP como nombres.
Nuestra recomendación habitual: si su hosting ya emite certificados públicos gratuitos de forma automática (AutoSSL en cPanel, Let's Encrypt con Certbot), siga usándolos. Así su sitio funciona con o sin Cloudflare delante. Use Origin CA cuando el servidor no pueda obtener un certificado público, y anote su fecha de vencimiento en el calendario.
Ajustes que acompañan al modo
Todos se encuentran en SSL/TLS > Edge Certificates.
Always Use HTTPS
Este ajuste redirige toda petición HTTP a HTTPS en el borde de Cloudflare, para todos los nombres de host de la zona. Está disponible en todos los planes. Cloudflare recomienda hacer la redirección aquí y no en el origen, para evitar bucles. No lo active si partes de su sitio todavía no pueden servir HTTPS; para esas partes use una regla de redirección específica. Tampoco corrige el contenido mixto: las páginas que cargan imágenes o scripts por http:// necesitan que se corrijan esos enlaces.
HSTS: potente, pero difícil de revertir
HTTP Strict Transport Security indica a los navegadores que usen solo HTTPS en su dominio durante un período (el max-age, hasta 12 meses en la configuración de Cloudflare). El panel de Cloudflare le obliga a aceptar una advertencia antes de activarlo, y con razón:
- Si HTTPS deja de funcionar, los visitantes no pueden entrar a su sitio durante todo el max-age. No pueden ignorar el error.
- includeSubDomains aplica la regla a todos los subdominios. Cualquier subdominio sin HTTPS (una intranet antigua, el portal de una impresora, una página alojada por un proveedor) queda inaccesible.
- Preload incluye su dominio en listas integradas en los navegadores. Cloudflare advierte que puede dejar completamente inaccesible un sitio sin HTTPS, y salir de esas listas es lento.
Nuestro enfoque: empiece con un max-age corto, deje includeSubDomains desactivado hasta revisar todos los subdominios y active preload solo después de meses con HTTPS funcionando sin problemas.
Versión mínima de TLS
Este ajuste rechaza a los visitantes cuyo software solo admite versiones antiguas de TLS. Se configura a nivel de zona en todos los planes. Fijarlo en TLS 1.2 es una base habitual y bloquea TLS 1.0 y 1.1, ya obsoletos. Antes, compruebe si algún equipo o integración antigua (una terminal de pago vieja o un cliente de API heredado) todavía se conecta a ese nombre de host.
Asegúrese de que nadie pueda rodear Cloudflare
Las protecciones que configura en Cloudflare solo se aplican al tráfico que pasa por Cloudflare. Si alguien descubre la IP real de su servidor, por el historial de DNS o por un registro de correo en el mismo servidor, puede conectarse directamente y saltarse su WAF y su configuración SSL. Cloudflare sugiere dos capas.
Authenticated Origin Pulls
Con Authenticated Origin Pulls, Cloudflare presenta un certificado de cliente (TLS mutuo) al conectarse a su servidor, y su servidor rechaza las conexiones que no lo tengan. Está disponible en todos los planes y solo funciona con Full o Full (strict), no con Off ni Flexible. Tenga en cuenta la limitación que documenta Cloudflare: el certificado global es compartido por todas las cuentas de Cloudflare, así que solo demuestra que la petición viene de la red de Cloudflare, no de su cuenta. Los certificados de zona o por nombre de host que usted sube sí están ligados a su zona.
Permita solo los rangos de IP de Cloudflare
Cloudflare publica sus rangos de IP en cloudflare.com/ips y recomienda bloquear el tráfico web hacia su origen desde cualquier otra fuente, con excepciones para proveedores de confianza. En un servidor Linux eso significa reglas de firewall que permitan los puertos 80 y 443 solo desde esos rangos, con sus excepciones agregadas antes de la regla final de bloqueo. Los rangos cambian pocas veces, y Cloudflare agrega los nuevos a la lista antes de usarlos, pero alguien debe encargarse de mantener la regla al día. Nuestra guía de endurecimiento de servidores Linux cubre los fundamentos del firewall.
Lista de verificación rápida
- Certificado válido en el origen (público u Origin CA), con su renovación o vencimiento controlado.
- Modo de cifrado en Full (strict), sin nombres de host que queden en Flexible por alguna regla.
- Always Use HTTPS activado, sin una redirección en el servidor que genere bucles.
- HSTS activado con cuidado, empezando con un max-age corto.
- Versión mínima de TLS en 1.2 después de comprobar que no hay clientes antiguos.
- Origen protegido con Authenticated Origin Pulls y/o un firewall que solo permita a Cloudflare.
Si no está seguro de qué modo usa su sitio, o quiere proteger bien el origen, nuestros equipos de ciberseguridad y administración de hosting web pueden revisarlo. Solicite una evaluación de TI gratuita y revisaremos su configuración de Cloudflare y de su servidor; atendemos a empresas en todo Miami-Dade y el sur de la Florida. Somos un proveedor de TI independiente que configura Cloudflare para sus clientes.
Fuentes
- Encryption modes (Cloudflare Docs)
- ERR_TOO_MANY_REDIRECTS (Cloudflare Docs)
- Cloudflare Origin CA (Cloudflare Docs)
- Always Use HTTPS (Cloudflare Docs)
- HTTP Strict Transport Security (Cloudflare Docs)
- Minimum TLS Version (Cloudflare Docs)
- Authenticated Origin Pulls (Cloudflare Docs)
- Cloudflare IP addresses (Cloudflare Docs)
