Advertencias de seguridad

Resumen

El 13 de octubre de 2016, alrededor de las 11:10 GMT, los visitantes de sitios web que utilizaban certificados TLS de GlobalSign, incluidos algunos alojados por Fastly, comenzaron a encontrarse con errores de validación de certificados TLS. Este problema lo causó información incorrecta de revocación de certificados publicada por nuestro proveedor de certificados, GlobalSign.

En esta advertencia de seguridad se describe el origen de este problema y las acciones que Fastly ha tomado para limitar su impacto en los clientes.

Impacto

Es posible que los visitantes de determinados sitios web se encontraran con errores de validación de certificados, como «NET::ERR_CERT_REVOKED», al acceder a sitios web que utilizan certificados de GlobalSign.

Este incidente afectó a algunos clientes de Fastly, ya que varias de nuestras opciones de TLS implican que los clientes de Fastly utilicen certificados adquiridos a su nombre de nuestra autoridad de certificación proveedora de certificados TLS, GlobalSign. Por ejemplo, los clientes que usan certificados compartidos de Fastly utilizan automáticamente certificados emitidos a través de GlobalSign. En cambio, no se vieron afectos por este incidente los clientes que utilizan nuestro hospedaje de certificados de clientes o un hospedaje de certificados de clientes de SNI con certificados emitidos por otros proveedores distintos de GlobalSign.

Se habrían producido errores esporádicos que habrían afectado a un número reducido de usuarios, quienes recibieron respuestas incorrectas del OCSP. El incidente duró un máximo de cuatro días para algunos visitantes, hasta que el equipo local del cliente almacenó la entrada del OCSP en caché. Desde Fastly revisamos nuestros niveles de tráfico en el momento del incidente y no observamos ninguna disminución notable en el tráfico de nuestros clientes.

Información detallada

Origen del incidente

Alrededor del 7 de octubre de 2016, la autoridad de certificación GlobalSign retiró un certificado cruzado y emitió una lista de revocación de certificados (CRL) en la que figuraba esa revocación. Debido a un error técnico por su parte a la hora de compilar respuestas del protocolo de estado de certificados online (OCSP), a partir del 13 de octubre de 2016, su respondedor del OCSP devolvió respuestas inexactas para una serie de certificados intermedios, lo cual llevó a algunos navegadores a deducir que se habían revocado varios certificados intermedios emitidos por GlobalSign.

Esta información se propagó a través de los respondedores del protocolo de estado de certificados online (OCSP) de GlobalSign. Además, en algunos casos, esta información quedó almacenada en caché por parte de CDN intermedias (no de Fastly) y en sistemas de clientes.

Estas respuestas inexactas del OCSP hicieron que algunos usuarios se encontraran con errores de validación de certificados en sitios web que utilizaban certificados de GlobalSign; entre ellos, muchos servicios alojados en Fastly. Como consecuencia, los usuarios tenían que aceptar fallos de los certificados para poder acceder al sitio web de destino, o simplemente no podían acceder.

Los errores habrían sido esporádicos y se habrían limitado a determinados usuarios, ya que no todos los navegadores validan el OCSP antes de permitir el acceso a un sitio web, y el incidente no afectó a otros mecanismos usados para indicar validez, como las listas de revocación de certificados (CRL).

Nuestra mitigación y respuesta

Una vez que se informó a Fastly del incidente, nos comunicamos con GlobalSign. GlobalSign investigó, determinó el origen del incidente y lo solucionó retirando las respuestas incorrectas del OCSP.

Sin embargo, para entonces ya se habían almacenado respuestas incorrectas en caché a varios niveles; entre ellos, en la memoria caché local del OCSP, que forma parte del sistema operativo. Normalmente, las respuestas se almacenan hasta la validez final de las respuestas de OCSP; GlobalSign emite respuestas de OCSP con una validez de cuatro días, lo que significa que, una vez recibidas por un cliente, el cliente las considerará válidas durante un total de cuatro días.

El respondedor del OCSP de GlobalSign utilizó una CDN distinta de Fastly que pudo haber almacenado respuestas en caché, por lo que su respondedor devolvió fallos incluso después de que se abordara la raíz del incidente. Además, debido al comportamiento de almacenamiento en caché de los sistemas operativos de los clientes, algunos de esos equipos que habían accedido a sitios web con una respuesta errónea del OCSP siguieron almacenando en caché dicha respuesta. Esto hizo que esos clientes no pudieran acceder a los sitios web afectados, incluso después de que GlobalSign solucionara el incidente.

Si bien los usuarios pueden limpiar manualmente la memoria caché del OCSP en su equipo, y GlobalSign había puesto a su disposición una guía sobre cómo hacerlo, este paso superaba la capacidad técnica de la mayoría de los usuarios finales. Además, las soluciones provisionales que propuso GlobalSign no funcionaron en todas las situaciones.

Fastly no consideró que esta mitigación fuese suficiente como para transmitirla a los usuarios finales de nuestros clientes. Después de una investigación minuciosa, Fastly ofreció a sus clientes otra opción para solucionar los incidentes:

• Los clientes con un mapa específico podían migrar a un nuevo certificado de un intermediario de GlobalSign que no se hubiese visto afectado por el incidente. Dado que la entrada en memoria caché solo afectaba al certificado antiguo, esto eliminaba el problema de raíz.


• Los clientes con certificado compartido podían migrar a otros puntos de conexión compartidos con certificados parecidos, pero nuevos. A los clientes que nos informaron de problemas se les ofreció la posibilidad de migrar a los nuevos mapas.

Fastly no podía tomar medidas para solucionar el origen del incidente sin consultar a nuestros clientes, ya que entendemos que algunos utilizan fijación de certificados (consulta «Más información» más adelante) en su aplicación cliente. Por ello, no pudimos migrar de manera inmediata a nuestros clientes existentes a un nuevo certificado intermedio sin su visto bueno.

Soluciones provisionales o permanentes

Los errores de revocación debían desaparecer al expirar el periodo de respuesta del OCSP, es decir, cuatro días después del incidente original. Para los clientes que migraron a los mapas actualizados que proporcionó Fastly, el problema habría quedado mitigado poco después de la migración.

Fastly entiende que los clientes confían en autoridades de certificación de terceros, así como en la CDN, para aceptar y distribuir correctamente el tráfico de usuarios. Como consecuencia de este incidente, estamos trabajando en las siguientes medidas de remedio y mitigación:

• Queremos asegurarnos de que nuestros planes de respuesta ante incidentes consideren los fallos de terceros en la entrega de certificados TLS como una razón potencial de una interrupción del servicio al cliente. A raíz de este incidente, hemos implementado la infraestructura necesaria para migrar rápidamente a través de las jerarquías de TLS y seguiremos implementando planes de contingencia adicionales para estos proveedores externos.


• La página de estado de Fastly (status.fastly.com) utilizaba un certificado de GlobalSign y también pudo haberse visto afectada por el mismo incidente. Estamos revisando nuestros mecanismos de mensajería de estado para garantizar que no recurran a servicios críticos que afectarían directamente a la distribución de contenido a través de la CDN, en este caso la misma autoridad de certificación.


• Estamos evaluando con GlobalSign maneras de aumentar la fiabilidad a la hora de proporcionar respuestas del OCSP para los certificados GlobalSign a los clientes de Fastly.

Trabajamos con nuestro proveedor GlobalSign para garantizar la implementación de planes que mitiguen futuros incidentes relacionados con la emisión y revocación de certificados.

Más información

Información sobre la comprobación de la validación y revocación de certificados

Cuando un navegador se conecta a un sitio web y evalúa un certificado X.509, el navegador suele querer asegurarse de que el certificado sigue siendo válido. Para facilitar este paso, X.509 tiene varias maneras de permitir a la autoridad de certificación confirmar la validez. A continuación, incluimos una explicación de referencia que ayudará a entender por qué determinados clientes se vieron o no afectados por problemas derivados de este incidente. En principio, la mayoría de los problemas se habrían dado en usuarios cuyo navegador o sistema operativo realizaba peticiones interactivas de OCSP:

1. CRL: las autoridades de certificación publican listas de revocación de certificados (CRL), que son archivos que contienen listas de certificados que ha revocado la autoridad de certificación. La mayoría de los navegadores no descargan interactivamente la CRL para cada petición, ya que suele ser de gran tamaño, y descargarla y validarla con cada conexión tendría un impacto importante en el rendimiento.


2. CRLSets: Google Chrome utiliza CRLSets como mecanismo para bloquear certificados rápidamente. En general, Chrome no realiza comprobaciones interactivas de OCSP y CRL, aunque ciertas bibliotecas de los sistemas operativos pueden realizar estas comprobaciones en un sistema que utilice Chrome para acceder a una página web. Google rastrea las listas CRL publicadas por las autoridades de certificación, extrae las que tienen valor y las pone a disposición de los navegadores Chrome para su descarga automática.


3. OCSP: las autoridades de certificación también habilitan un respondedor del protocolo de estado de certificados online (OCSP), que un navegador puede consultar de manera interactiva para comprobar si el certificado sigue siendo válido. Muchos navegadores realizan una comprobación en el OCSP de manera interactiva al validar un certificado TLS. Cuando se recibe una respuesta correcta del OCSP, el resultado —ya sea positivo (válido) o negativo (no válido)— se almacena en una parte de la caché del OCSP local del sistema operativo. Por lo común, las respuestas se almacenan hasta la validez final de las respuestas del OCSP, que en el caso de GlobalSign era de cuatro días.


4. Grapado OCSP: el servidor web también puede entregar las respuestas del OCSP mediante un mecanismo llamado grapado OCSP. En este caso, el servidor web recupera la confirmación de la validez, firmada por la autoridad de certificación, y la «grapa» durante el protocolo de enlace TLS. El grapado OCSP tiene ventajas tanto en rendimiento como en seguridad, ya que no requiere una conexión independiente con el respondedor de OCSP de la autoridad de certificación. El grapado es una práctica óptima para la revocación de certificados y está desplegado en todos los servicios de Fastly.

Además de la validez, los navegadores también comprueban si un certificado es válido para un sitio concreto a través de la fijación de clave pública. Este mecanismo consiste en que la aplicación cliente, ya sea una aplicación o un navegador, valida si se espera el certificado raíz, intermedio o final de un servicio. Se pueden codificar los fijadores de forma rígida en el cliente, o distribuirlos mediante la extensión de fijación de clave pública para HTTP (HPKP). La fijación es una valiosa función de seguridad de uso común que reduce el riesgo de que se manipule una autoridad de certificación para que emita un certificado normalmente válido para un servicio. Sin embargo, la fijación también puede reducir la flexibilidad de un sitio web a la hora de pasar con rapidez a otra jerarquía de certificados. En este incidente, el posible uso de la fijación por parte de nuestros clientes limitó la capacidad de Fastly de migrar automáticamente y de forma transparente a todos los clientes a otra jerarquía.

Informe de incidentes de GlobalSign

GlobalSign ha publicado un informe de incidentes con información sobre su respuesta al incidente en https://www.globalsign.com/en/customer-revocation-error/. Este documento contiene más información sobre las medidas que ha adoptado GlobalSign para evitar que se repita este tipo de incidentes.