Advertencias de seguridad

Dotación de medidas de seguridad a TLS en la conexión edge a origen

18 de febrero de 2016

Resumen


Fastly ha solucionado un problema en la configuración predeterminada de nuestra seguridad de la capa de transporte (TLS) que impedía la correcta validación de certificados al establecerse conexión con los servidores de origen del cliente. Los servicios creados después del 6 de septiembre de 2015 no se vieron afectados. Esta advertencia describe el problema para informar a nuestros clientes de su posible vulnerabilidad, la solución que hemos desarrollado y las mejoras adicionales que vamos a implantar.


A esta vulnerabilidad se le ha asignado la clasificación de gravedad de seguridad de Fastly ALTA.




Impacto


Si el personal de ingeniería de Fastly no se ha puesto en contacto contigo directamente, no es necesario que realices ninguna acción; tus servicios están protegidos.


Las conexiones TLS que no validen los certificados son vulnerables a ataques de intermediario (MITM). Este comportamiento era exclusivo de las conexiones realizadas entre Fastly y los servidores de origen del cliente a través de HTTPS.


Fastly dispone sus puntos de presencia (POP) en los principales sitios de emparejamiento de internet y recupera el contenido procedente de los servidores de origen a través de las redes de proveedores ubicadas lo más cerca posible del eje central de internet. De este modo se dificultan más los ataques de intermediario, pero no los hace imposibles. Estas redes aún son susceptibles de sufrir secuestros de BGP, envenenamientos de caché DNS o ataques de inyección de tráfico malicioso; por lo tanto, la validación de certificados sigue siendo una tecnología de defensa importante. Fastly ha habilitado la validación de certificados para todos los clientes que tengan servidores de origen TLS que sean compatibles con esta. Nos hemos puesto en contacto directo con todos los clientes que tienen servidores de origen que no admiten la validación debido a una configuración incorrecta, y el equipo de ingeniería ha colaborado con ellos para corregirla antes de habilitar la validación en sus servicios.


Fastly ayudó activamente a clientes que tenían configuraciones incorrectas de TLS del servidor de origen, como discrepancias en el nombre del host. Ahora que la mayoría de estos clientes han solucionado la vulnerabilidad de su configuración, publicamos una advertencia de seguridad más amplia.




Información detallada


Clientes, edges y orígenes




Fastly opera como proxy de caché inverso. Cuando hablamos de conexiones HTTPS, deben tenerse en cuenta dos elementos. El primero, la conexión desde el navegador del cliente hasta la red de Fastly (cliente a edge) para solicitar contenido. Y el segundo, cuando el contenido no está almacenado en caché, la petición destinada al servidor de origen del cliente (edge a origen).


Fastly admite TLS para la conexión cliente a edge; además, ajustamos frecuentemente la configuración de modo que se amolde a las prácticas recomendadas y nos ayude a anticiparnos a vulnerabilidades anunciadas. Aparte de para la conexión cliente a edge, Fastly admite TLS para la conexión edge a origen. Era precisamente este componente de edge a origen el que no validaba los certificados.







Validación de certificados


TLS proporciona autenticación además de confidencialidad. Como parte del protocolo de enlace TLS, el servidor remoto ofrece un certificado X509 que asocia una clave pública a una identidad (y, lo más importante, un nombre de dominio). Esto por sí solo no es suficiente para autenticar la conexión, ya que cualquiera puede suplantar una identidad y proporcionar su propia clave pública. Deberá emitir el certificado una autoridad de certificación (CA) de confianza, la cual se encarga de comprobar que la identidad alegada es legítima.


Al revisar nuestra configuración de TLS para la conexión edge a origen, nos dimos cuenta de que, debido a un descuido al añadir a Varnish compatibilidad con TLS, la validación de certificados no estaba activada por defecto. Esto significa que no validamos el nombre del host que figuraba en el certificado ni comprobamos si una CA de confianza se había encargado de su emisión. Las conexiones TLS que no validen los certificados son vulnerables a ataques de intermediario (MITM).


Una vez descubierto el problema, comenzamos inmediatamente a evaluar prioridades y planificar una solución. Lamentablemente, la solución se complica por el hecho de que nuestra validación de certificados ha posibilitado que parezcan estar operativas configuraciones del servidor de origen que en realidad no funcionan. Si se habilita la validación estricta de estos servicios, quedarían interrumpidos. Así, intentar corregir el comportamiento de validación al tiempo que se evitan interrupciones resulta mucho más complejo aún.




Soluciones provisionales y permanentes


Para cuantificar el problema, comprobamos una por una la configuración de TLS de cada servidor de origen en busca de servicios que se interrumpiesen al activar la validación. Basándonos en los resultados del análisis, elaboramos una lista de configuración correcta y una lista de configuración incorrecta. En todos los servicios nuevos y en los que figuran en la lista de configuración correcta, la validación de TLS ya está activada por defecto. A través de nuestro equipo de soporte al cliente, nos hemos puesto en contacto con todos los clientes que tengan servicios en la lista de configuración incorrecta. Para que estos clientes puedan admitir la validación, va a ser necesario realizar cambios en las configuraciones de origen. Con el fin de ayudar a los clientes a realizar los cambios necesarios, hemos añadido documentación en la que se detallan problemas comunes de origen TLS y cómo solucionarlos. Además de arreglar la validación de los certificados, hemos aprovechado la coyuntura para mejorar nuestra compatibilidad con TLS.




Más información


Mejoras de TLS


Además de solucionar la vulnerabilidad, hemos dejado de utilizar conjuntos de cifrado RC4 y hemos dado un mayor control sobre las conexiones TLS edge a origen. Con el fin de eliminar proactivamente cualquier problema adicional, también hemos sometido nuestra configuración de TLS a rigurosas pruebas utilizando el conjunto de casos límite de TLS que ofrece el fantástico proyecto TLS-O-Matic. La necesidad de un paquete de pruebas de este tipo pone de relieve la complejidad de TLS y la dificultad que el software cliente tiene para gestionar el protocolo de forma segura. Desde que activamos la validación de certificados como opción predeterminada, el stack de Fastly TLS supera todos los casos de prueba de TLS-O-Matic pertinentes.


Si tienes alguna duda o pregunta o quieres asegurarte de que la configuración de tus sistemas de origen es la más segura posible, ponte en contacto con support@fastly.com. Para acceder a informes de vulnerabilidades y a consultas no relacionadas con clientes, ponte en contacto con security@fastly.com.

Suscríbete a las advertencias de seguridad.

Al enviar la solicitud, das tu consentimiento para que tus datos se envíen a Fastly en los Estados Unidos y sean tratados conforme a nuestra Política de privacidad.

¿List@ para empezar?

Ponte en contacto o crea una cuenta.