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

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

Como todas las redes expuestas a Internet, las CDN deben protegerse de ataques en ruta, fugas de datos e intentos de saturar la red del servidor de origen mediante ataques DDoS. Una CDN puede contar con varias estrategias para mitigar vulnerabilidades, tales como una encriptación SSL/TLS adecuada y un hardware de encriptación especializado.

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

La seguridad de la capa de transporte (TLS) es un protocolo para encriptar los datos que se envían por Internet. TLS surgió de la capa de conexión segura (SSL), el primer protocolo de encriptación web de uso generalizado, y tiene como objetivo solucionar la mayoría de fallos de seguridad del protocolo anterior. Por motivos históricos, el sector sigue usando los términos indistintamente. Cualquier sitio web que visites que empiece por https:// en lugar de de http:// usa TLS/SSL para la comunicación entre navegador y 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.

El protocolo TLS está diseñado para ofrecer:

1. Autenticación: capacidad de verificar 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 falsificaciones y manipulaciones.

Más información sobre SSL/TLS gratuito de Cloudflare.

¿Qué es un certificado SSL?

Para activar TLS, un sitio web necesita un certificado SSL y su clave correspondiente. Los certificados son archivos que incluyen información del 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 verificar que la información del certificado sea correcta. Al confiar en el certificado, confías en que la autoridad de certificación ha realizado su auditoría.

Los sistemas operativos y los navegadores suelen contar con 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 sea de confianza, el navegador avisa al visitante de que el sitio podría ser sospechoso.

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 más obsoleta y de grado inferior, lo habitual es que tenga una clasificación más baja y sea más vulnerable a riesgos.

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

Si somos realistas, el sistema de seguridad deficiente de servidor a perímetro sigue siendo una vulnerabilidad y se debería evitar, sobre todo si se tiene en cuenta lo fácil que es mejorar la seguridad de un servidor de origen mediante el uso de la encriptación de origen gratuita.

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

Una conexión de SSL/TLS funciona de forma diferente que una conexión TCP/IP tradicional. Una vez se hayan realizado las fases iniciales de la conexión TCP, se produce un intercambio independiente para establecer la conexión segura. Este artículo se refiere al dispositivo que solicita la conexión segura como "cliente" y al dispositivo que sirve la conexión segura como "servidor", como sucede con un usuario que carga una página web encriptada con SSL/TLS.

Primero, el protocolo de enlace TCP/IP se lleva a cabo en 3 pasos:

1. El cliente envía un paquete SYN al servidor para poder iniciar la conexión.
2. El servidor responde a ese paquete inicial con un paquete SYN/ACK para admitir la comunicación.
3. Por último, el cliente devuelve un paquete ACK para confirmar la recepción del paquete del servidor. Después de completar esta secuencia de envío y recepción de paquetes, la conexión TCP se abre y es capaz de enviar y recibir datos.

Una vez se haya realizado el protocolo de enlace TCP/IP, comienza el protocolo de enlace de encriptación de TLS. Los procesos detallados de la implementación del protocolo de enlace TLS no se incluyen en esta guía. En su lugar, nos centraremos en el objetivo principal 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 que se usará en la comunicación.
2. El cliente y el servidor toman medidas para asegurar que haya una comunicación mutua auténtica entre ambas partes.
3. Se intercambia una clave, que se utilizará para comunicaciones encriptadas posteriores.

En el siguiente diagrama se muestran los pasos que contiene el protocolo de enlace TCP/IP y el protocolo de enlace TLS. Ten en cuenta que cada flecha representa una comunicación separada, la cual debe viajar físicamente entre el cliente y el servidor. Debido a que el número total de mensajes de ida y vuelta se incrementa al usar la encriptación de TLS, aumentan los tiempos de carga de la página.

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.

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

Las optimizaciones de SSL pueden reducir el RTT y mejorar el tiempo de carga de la página. A continuación, presentamos tres maneras de optimizar una conexión de TLS:

Reanudación de la sesión de TLS: una CDN puede mantener activa más tiempo una conexión entre el servidor de origen y la red de CDN si se reanuda 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 reciba solicitudes adicionales mientras se mantiene la conexión a la CDN, los visitantes adicionales al sitio web experimentarán una latencia más baja.

El coste 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 necesita un viaje de ida y vuelta, a diferencia del protocolo de enlace TLS completo, que necesita dos. Además, la reanudación de sesión no requiere una aritmética de campo finita (a diferencia de las nuevas sesiones), así que el coste de CPU para el cliente es casi inapreciable si se compara con el de un protocolo de enlace TLS completo. Para los usuarios de dispositivos móviles, la mejora del rendimiento mediante la reanudación de sesión supone una experiencia de navegación mucho más reactiva y ahorro de batería.

Habilitar el inicio falso de TLS: cuando un visitante ve el sitio por primera vez, la reanudación de sesión mencionada anteriormente no será útil. El inicio falso de TLS permite que el emisor envíe datos de la aplicación sin un protocolo de enlace TLS completo.

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

Reanudación de tiempo de viaje de ida y vuelta cero (0-RTT): permite la reanudación de la sesión sin añadir latencia de RTT a la conexión. En las conexiones reanudadas que usan TLS 1.3 y 0-RTT, aumenta la velocidad de conexión, lo que agiliza y mejora la experiencia en los sitios web que los usuarios visitan con frecuencia. Este aumento de la velocidad es especialmente evidente en las redes móviles.

0-RTT es una mejora eficaz, pero tiene sus inconvenientes en materia de seguridad. Para eliminar el riesgo de lo que se conoce como un ataque de repetición, un servicio de CDN puede implementar restricciones en el tipo de solicitudes de HTTP y los parámetros permitidos. Para más información, consulta la introducción a 0-RTT.

Protección de 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 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 adoptar otras medidas para proteger una conexión de 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.