Las estrategias de CDN para mitigar las vulnerabilidades incluyen el cifrado SSL/TLS adecuado y el hardware de encriptación especializado.
Después de leer este artículo podrás:
Contenido relacionado
Fiabilidad de la CDN
Rendimiento de la CDN
Anycast
Punto de intercambio de Internet (IXP)
Tiempo de ida y vuelta (RTT)
Suscríbete a theNET, el resumen mensual de Cloudflare sobre las ideas más populares de Internet.
Copiar el enlace del artículo
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.
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 información importante. Debido al modo en el que está diseñado Internet, en el que se transfieren datos a través de diversas ubicaciones, es posible interceptar paquetes de información importante a medida que se desplazan por todo el mundo. Con el uso de un protocolo criptográfico, únicamente el destinatario previsto puede decodificar y acceder a la información. Se previene así que los intermediarios decodifiquen el contenido de los datos transferidos.
Más información sobre SSL/TLS gratuito de Cloudflare.
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.
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.
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.
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.
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.
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.
A título ilustrativo, se puede decir que el protocolo de enlace TCP tarda unos 50 ms y el de TLS unos 110 ms. Esto se debe principalmente al tiempo que tardan los datos en enviarse entre el cliente y el servidor, y viceversa. El concepto de tiempo de ida y vuelta (RTT), que es la cantidad de tiempo que tarda la información en ir y volver de un dispositivo a otro, se puede utilizar para cuantificar el "coste" de creación de una conexión. Si se deja sin optimizar y sin el uso de una CDN, el RTT adicional representa un aumento en la latencia y una reducción en el tiempo de carga para los usuarios finales. Por suerte, se pueden llevar a cabo optimizaciones para mejorar el tiempo de carga total y reducir el número de viajes de ida y vuelta.
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.
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.
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.
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.
Una de las vulnerabilidades de seguridad más importantes de las propiedades web en la red moderna es el uso de ataques de denegación de servicio distribuido (DDoS). A lo largo del tiempo, los ataques DDoS han aumentado su tamaño y complejidad, y los atacantes usan botnets para realizar ataques de tráfico a sitios web. Una CDN grande y configurada correctamente tiene la ventaja potencial de la escala como factor de protección ante ataques DDoS. Al tener ubicaciones de centros de datos suficientes y capacidades de ancho de banda considerables, una CDN es capaz de resistir y mitigar una cantidad de ataques de tráfico entrante que podrían sobrecargar con facilidad 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.