Seguridad SSL/TLS para la CDN | Seguridad de la CDN

Las estrategias de CDN para mitigar las vulnerabilidades incluyen el cifrado SSL/TLS adecuado y el hardware de encriptación especializado. Consulta la guía de CDN.

Metas de aprendizaje

Después de leer este artículo podrás:

  • Entender cómo funciona la seguridad SSL/TLS para la CDN
  • Analizar las optimizaciones de una CDN para SSL/TLS
  • Descubrir cómo una CDN puede mejorar una versión desactualizada de un certificado SSL/TLS
  • Conocer cómo una CDN puede ayudar a mitigar ataques DDoS

Copiar el enlace del artículo

¿Cuáles son los riesgos de seguridad de una CDN?

Al igual que todas las redes expuestas a Internet, las CDN deben protegerse de los ataques en ruta, las fugas de datos y de los intentos de saturar la red del servidor de origen mediante ataques DDoS. Una CDN puede tener múltiples estrategias para mitigar vulnerabilidades, incluida una encriptación SSL/TLS adecuada y un hardware de encriptación especializada.

¿Qué es la encriptación SSL/TLS?

Seguridad de la capa de transporte (TLS) es un protocolo para encriptar los datos que se envían a través de Internet. TLS surgió de la capa de conexión segura (SSL), el primer protocolo de encriptación web ampliamente adoptado, para corregir la mayoría de las fallas de seguridad del protocolo anterior. Por motivos históricos, el sector sigue usando los términos indistintamente. Cualquier sitio web que visites que comience con https:// en lugar de http:// utiliza TLS/SSL para la comunicación entre un navegador y un servidor.


Es necesario llevar a cabo prácticas de encriptación adecuadas para evitar que los atacantes accedan a datos importantes. Debido a que Internet está diseñado de manera que los datos se transfieren a través de muchas ubicaciones, es posible interceptar paquetes de información importante a medida que se desplazan por todo el mundo. Mediante el uso de un protocolo criptográfico, solo el destinatario previsto puede decodificar y leer la información, y se evita que los intermediarios decodifiquen el contenido de los datos transferidos.

El protocolo TLS está diseñado para ofrecer 3 componentes:

  1. Autenticación: la capacidad de comprobar la validez de las identificaciones proporcionadas.
  2. Encriptación: capacidad de ocultar la información enviada de un servidor a otro.
  3. Integridad: capacidad de detectar las falsificaciones y manipulaciones.

¿Qué es un certificado SSL?

Para activar TLS, un sitio necesita un certificado SSL y una clave correspondiente. Los certificados son archivos que contienen información sobre el propietario de un sitio y la mitad pública de un par de claves asimétricas. Una autoridad de certificación firma digitalmente el certificado para comprobar que la información en el certificado sea correcta. Al confiar en el certificado, confías en que la autoridad de certificación ha hecho su auditoría.

Gráfico de error SSL/TLS

Los sistemas operativos y los navegadores suelen tener una lista de autoridades de certificación en las que confían implícitamente. Si un sitio web presenta un certificado firmado por una autoridad de certificación que no es de confianza, el navegador advierte al visitante que algo podría estar sucediendo.


Los certificados y la forma en que se aplican también pueden calificarse de forma independiente en función de su solidez, el protocolo de soporte y otras características. Las calificaciones pueden cambiar con el tiempo según vayan apareciendo implementaciones nuevas y mejores, u otros factores que reduzcan la seguridad general de una implementación de certificación. Si un servidor de origen tiene una implementación de seguridad SSL de grado inferior más antiguo, por lo general se calificará de manera más deficiente y puede ser vulnerable a riesgos.


Una CDN tiene la ventaja añadida de ofrecer seguridad a los visitantes de las propiedades alojadas en su red utilizando un certificado proporcionado por la CDN. Debido a que los visitantes se conectan solo a la CDN, un certificado más antiguo o menos seguro, en uso entre el servidor de origen y la CDN no afectará la experiencia del cliente.

diagrama de certificados SSL/TLS autofirmados

Siendo realistas, esta seguridad más débil de servidor al perímetro sigue representando una vulnerabilidad y debería evitarse, sobre todo teniendo en cuenta la facilidad con la que es posible mejorar la seguridad de un servidor de origen utilizando la encriptación de origen gratuita.

diagrama de certificados SSL/TLS autofirmados

Una seguridad adecuada también es importante para la búsqueda orgánica; las propiedades web encriptadas dan como resultado una mejor clasificación en la búsqueda de Google.


Una conexión SSL/TLS funciona de manera diferente a una conexión TCP/IP tradicional. Una vez que se realizan las etapas iniciales de la conexión TCP, se produce un intercambio por separado para configurar la conexión segura. Este artículo hace referencia al dispositivo que solicita la conexión segura como cliente y al dispositivo que sirve la conexión segura como el servidor, como es el caso con un usuario que carga una página web cifrada con SSL/TLS.

Primero, el protocolo de enlace de TCP/IP se realiza en 3 pasos:

  1. El cliente envía un paquete SYN al servidor para iniciar la conexión.
  2. El servidor responde al paquete inicial con un paquete SYN/ACK para reconocer la comunicación.
  3. Finalmente, el cliente devuelve un paquete ACK para reconocer la recepción del paquete del servidor. Tras finalizar esta secuencia de envío ida y vuelta del paquete, la conexión TCP está abierta, y puede enviar y recibir información.
diagrama de establecimiento de comunicación de 3 vías del TCP

Una vez que se ha producido el protocolo de enlace de TCP/IP, comienza el protocolo de enlace de encriptación TLS. Los procesos detallados detrás de una implementación de protocolo de enlace TLS están fuera del alcance de esta guía. En su lugar, nos centraremos en el propósito central del protocolo de enlace y en el tiempo necesario para completar el proceso.

El protocolo de enlace TLS incluye tres elementos desde un nivel superior:

  1. El cliente y el servidor negocian las versiones de TLS y el tipo de cifrado criptográfico que se utilizará en la comunicación.
  2. El cliente y el servidor toman medidas para asegurar una comunicación mutuamente auténtica.
  3. Se intercambia una clave para utilizarla en las futuras comunicaciones encriptadas.

En el diagrama siguiente, se visualizan cada uno de los pasos involucrados en un protocolo de enlace TCP/IP y un protocolo de enlace TLS. Ten en cuenta que cada flecha representa una comunicación independiente que debe viajar físicamente entre el cliente y el servidor. Dado que el número total de mensajes de ida y vuelta aumenta cuando se utiliza la encriptación TLS, los tiempos de carga de la página web aumentan.

Diagrama de protocolo de enlace SSL/TLS

A título ilustrativo, se puede decir que el protocolo de enlace de TCP tarda unos 50 ms y el protocolo de enlace de TLS puede tardar unos 110 ms. Esto se debe en gran parte al tiempo que lleva el envío de datos en ambos sentidos, entre el cliente y el servidor. La idea del tiempo de ida y vuelta (RTT), que es la cantidad de tiempo que tarda la información en viajar de un dispositivo a otro y viceversa, se puede utilizar para cuantificar qué tan "caro" es crear una conexión. Si no se optimiza y no se utiliza una CDN, el RTT adicional representa un aumento de la latencia y una reducción del tiempo de carga para los usuarios finales. Por suerte, existen optimizaciones que se pueden realizar para mejorar el tiempo total de carga y reducir el número de viajes de ida y vuelta.

¿Cómo se puede mejorar la latencia de SSL?

Las optimizaciones SSL pueden reducir el RTT y mejorar el tiempo de carga de la página. Aquí se muestran 3 formas en las que se puede optimizar una conexión TLS:


Reanudación de la sesión de TLS: una CDN puede mantener activa una conexión entre el servidor de origen y la red CDN durante más tiempo al reanudar la misma sesión para solicitudes adicionales. Mantener la conexión activa permite ahorrar tiempo dedicado a renegociar la conexión entre la CDN y el servidor de origen cuando el cliente necesita una recuperación de origen sin caché. Siempre que el servidor de origen recibe solicitudes adicionales mientras se mantiene la conexión a la CDN, los visitantes adicionales del sitio experimentarán una latencia más baja.

infografía en tiempo real de la reanudación de la sesión

El costo total de una reanudación de sesión es inferior al 50 % de un protocolo de enlace TLS completo, principalmente porque la reanudación de sesión solo cuesta un viaje de ida y vuelta mientras que un protocolo de enlace TLS completo requiere dos. Además, la reanudación de una sesión no requiere ninguna aritmética de campo finito grande (las sesiones nuevas sí lo hacen), por lo que el costo de CPU para el cliente es casi insignificante en comparación con un protocolo de enlace TLS completo. Para los usuarios de dispositivos móviles, la mejora de rendimiento mediante la reanudación de la sesión significa una experiencia de navegación mucho más reactiva y ahorro de batería.

infografía de tiempo de CPU de la reanudación de la sesión

Habilitar el inicio falso de TLS: cuando un visitante está viendo el sitio por primera vez, la reanudación de la sesión mencionada anteriormente no será útil. El inicio falso de TLS permite al remitente enviar datos de la aplicación sin un protocolo de enlace TLS completo.

diagrama de protocolo de enlace de inicio falso SSL/TLS

El inicio falso no modifica el protocolo TLS en sí, solo modifica el tiempo en el que se transfieren los datos. Una vez que el cliente inicia el intercambio de claves, se puede garantizar la encriptación y se inicia la transferencia de datos. Esta modificación reduce el número total de viajes de ida y vuelta, al reducir la latencia requerida en 60 ms.


Reanudación de tiempo de viaje de ida y vuelta cero (0-RTT): permite la reanudación de la sesión sin agregar la latencia RTT a la conexión. Para las conexiones reanudadas con TLS 1.3 y 0-RTT, se mejora la velocidad de conexión, lo que permite lograr una experiencia web más rápida y fluida para los sitios web que los usuarios visitan con regularidad. Este aumento de velocidad es especialmente notable en las redes móviles.


0-RTT es una mejora eficaz, pero compromete en cierto modo la seguridad. Para superar el riesgo de lo que se conoce como un ataque de repetición, un servicio CDN puede implementar restricciones en el tipo de solicitudes HTTP y en los parámetros permitidos. Para obtener más información, consulta la introducción al 0-RTT.

Protección CDN contra ataques DDoS

Una de las vulnerabilidades de seguridad más importantes de las propiedades web en la red moderna es el uso de los ataques de denegación de servicio distribuido (DDoS). Con el tiempo, los ataques DDoS han aumentado en tamaño y complejidad, y los atacantes utilizan botnets para atacar los sitios web con tráfico de ataque. Una CDN grande y correctamente configurada tiene el beneficio potencial de escala como un factor de protección contra DDoS. Al tener suficientes ubicaciones de centros de datos y capacidades de ancho de banda considerables, una CDN puede soportar y mitigar una cantidad de tráfico de ataque entrante que fácilmente abrumaría al servidor de origen objetivo.


Se pueden tomar otras medidas para asegurar una conexión TLS. Consulta más información sobre la CDN de Cloudflare y no te pierdas la publicación en el blog Estar al día de los ataques contra TLS. Comprueba si tu sitio web usa HTTPS correctamente en el Centro de diagnóstico de Cloudflare.