Incidente de caída de Tailscale.com ocurrido el 7 de marzo de 2024

 (tailscale.com)
2 puntos por GN⁺ 2024-04-01 | 1 comentarios | Compartir por WhatsApp
  • El 7 de marzo de 2024, tailscale.com estuvo fuera de servicio durante unos 90 minutos debido a un certificado TLS vencido, aunque el impacto se limitó principalmente a la documentación y al sitio de marketing
  • El problema salió a la luz unos 90 días después del rediseño del sitio web y la migración a un nuevo hosting en diciembre de 2023; una configuración de proxy propio para compensar entornos sin soporte de IPv6 impidió la renovación automática
  • El prober de monitoreo de vencimiento de certificados revisaba solo la ruta IPv6 y pasaba por un proxy con un certificado válido aparte, por lo que no detectó que los certificados reales de tailscale.com y www.tailscale.com estaban por vencer
  • La mayoría del uso habitual de Tailscale no se interrumpió, pero sí se vieron afectados la documentación, el blog, install.sh y el flujo de acceso a la consola de administración para usuarios que no conocían la URL directa
  • Tailscale se recuperó eliminando registros AAAA adicionales y renovando manualmente el certificado; pasará por un esquema de renovación manual de corto plazo y verificaciones separadas para IPv4/IPv6, con el objetivo de ofrecer soporte IPv6 más directo

Por qué se pasó por alto el vencimiento del certificado

  • El 7 de marzo de 2024 vencieron los certificados TLS de tailscale.com y www.tailscale.com, lo que interrumpió el acceso al sitio durante unos 90 minutos
  • En diciembre de 2023, Tailscale migró a un nuevo proveedor de hosting junto con una renovación importante de su sitio web
  • Como el nuevo proveedor de hosting no ofrecía soporte IPv6 de forma predeterminada, Tailscale operó su propio proxy para procesar solicitudes IPv6 y configuró registros AAAA adicionales
  • El proveedor de hosting consideró esta configuración como una “misconfiguration” y envió una alerta, pero en esa alerta no se indicaba que dicha configuración impediría completar la renovación automática del certificado
  • El prober para monitorear el vencimiento de certificados solo revisaba la ruta IPv6
    • El prober pasaba por el proxy propio
    • El proxy tenía un certificado válido administrado por separado
    • Por eso, el vencimiento real de los certificados de tailscale.com y www.tailscale.com no quedó expuesto de antemano

Impacto visible para los usuarios

  • El impacto se concentró en recursos y flujos de instalación que dependen del sitio web
    • La documentación de Tailscale, el blog y otros materiales de referencia basados en el sitio web no estuvieron accesibles durante la caída
    • La consola de administración y las páginas de configuración en sí no se vieron afectadas, pero los usuarios que no sabían cómo ir directamente a https://login.tailscale.com/ podían pensar que esa página estaba offline
    • El script de instalación rápida no estaba disponible, lo que afectó algunas instalaciones e instalaciones automatizadas
  • Los dominios que efectivamente sirven la instalación de paquetes de Tailscale sí estaban accesibles, y se considera que la interrupción de la resolución mediante el mecanismo go get de Go fue mínima gracias al caching
  • Por el diseño de Tailscale, la mayoría de los usuarios no sufrió interrupciones en la mayoría de los casos de uso durante este incidente, y gracias al principio de conexión directa la red depende menos de la disponibilidad inmediata de endpoints específicos como tailscale.com

Recuperación y prevención de recurrencias

  • Tras identificar el problema, Tailscale eliminó temporalmente los registros AAAA “adicionales” y renovó manualmente los certificados relacionados
  • Con esta medida, la interrupción visible para los usuarios se resolvió de inmediato, y los registros se restauraron poco después para ofrecer el sitio y los servicios por IPv6
  • El problema de renovación automática sigue pendiente, por lo que a corto plazo planean renovar directamente los certificados con recordatorios de calendario redundantes y una ventana designada de renovación manual
  • La infraestructura de prober se actualizará para verificar por separado los endpoints IPv4 e IPv6
  • A largo plazo, el objetivo es dar soporte a IPv6 de forma más directa en la infraestructura del sitio web, con una estructura que no requiera un proxy propio

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-04-01
Opiniones en Hacker News

  • Ahora veo los certificados que expiran como el nuevo DNS de las caídas
    Aun así, todavía me sorprende lo bien hecho que está Tailscale. Soy más bien un usuario ligero, pero accedo con Tailscale a dos lugares: algunos servidores on-premises y un entorno de producción en AWS
    Puedo trabajar desde cualquier lugar. Un fin de semana intentaba desplegar un contenedor ECS, pero el wifi local era tan lento que el despliegue seguía agotando el tiempo de espera
    Así que entré por SSH a una máquina de desarrollo on-premises, hice git pull del código más reciente y desplegué desde ahí. Tanto on-premises como AWS estaban seguros, sin puertos abiertos, y con solo levantar un agente de Tailscale en una EC2 pequeña de AWS también puedo probar la base de datos Aurora de producción sin puertos abiertos
    Cuando hay que darle acceso de red a otro desarrollador, Tailscale también lo hace muy fácil, y revocar permisos igual. Este despliegue podría haberse manejado con algo como GitHub Actions para evitar el problema de una mala conexión a internet, pero quería hacerlo manualmente y Tailscale lo hizo posible

    • GitHub Actions sigue siendo útil incluso al desplegar con Tailscale. Ahora tenemos abierto el puerto SSH de una VM en la nube en un puerto no estándar para que el worker de GHA pueda entrar por SSH e iniciar el despliegue
      A futuro queremos usar esta action para que cualquier worker de GHA pueda acceder a la máquina de despliegue sin exponer puertos: https://github.com/tailscale/github-action
    • En conexiones inestables uso mosh y GNU screen. Funciona sorprendentemente bien incluso si se corta cada 10 segundos

  • Otro incidente causado por un certificado vencido
    Como parte del postmortem, recomiendo separar el script de instalación del sitio de marketing o tener alguna ruta alternativa. Así, las actividades del sitio de marketing quedan fuera del camino crítico de las operaciones de los clientes. Estas cosas pasan con frecuencia, por eso da más pena cuando ya estaban tan cerca de mantener un aislamiento razonable
    Si uno sigue el uptime de varios proveedores, es más común de lo esperado que se caigan partes de sitios como GitHub o Zendesk. Y aun así, ellos están entre los buenos ejemplos

    • La prioridad de seguridad del sitio de marketing suele ser menor que la del producto en sí, y el script de instalación normalmente debería protegerse a un nivel similar al del producto
    • Me pregunto si existe algún servicio que monitoree todos los certificados y sus fechas de vencimiento
      Cloudflare parece encargarse bastante de esto si alojas el dominio con ellos, pero eso implica tener que usar Cloudflare

  • Es el mismo error que cometimos en una empresa anterior. En la home del sitio de marketing www.foo.com pusimos un enlace a la página de login de la app web app.foo.com
    Recién cuando se cayó por primera vez el sitio de marketing nos dimos cuenta de que el plan de hosting de 40 dólares al mes no era solo un sitio de marketing, sino infraestructura crítica. Literalmente era un hosting de 40 dólares soportando carga. La app no estaba caída, pero los usuarios pensaban que sí
    Aprendimos que los usuarios simplemente siguen el camino que les preparamos; muchas veces no saben que existe otro, y si quitas ese único camino, algunos usuarios quedan completamente perdidos

    • Si escribes tailscale en el navegador, el primer resultado es tailscale.com. Como no uso tan seguido la consola de administración de Tailscale, no me molesto en memorizar otra URL
      Antes, al escribir cloudflare, el navegador autocompletaba dash.cloudflare.com, pero después de visitar una sola vez el sitio cloudflare.com, ese pasó a ser el primer resultado, y terminé haciendo lo mismo con Cloudflare

  • Este equipo es realmente bueno, pero me parece que el precio es demasiado alto. Es casi imposible venderle a la gerencia un control de acceso decente para una VPN que cuesta 18 dólares al mes, y los tiers bajos son difíciles de vender sin esa función

    • De verdad me da curiosidad con qué comparan internamente a Tailscale. Tailscale hace mucho más que una VPN simple
      Me pregunto cuáles son las opciones más baratas y si también ofrecen funciones de SSH, autenticación de red OAuth para servicios automatizados, configuración de un balanceador de carga para nodos VPN dentro de un clúster Kubernetes y automatización de solicitudes de certificados ACME vía Let’s Encrypt
      Solo enumerando algunas funciones que uso en el tier gratuito, hay muchas que normalmente uno no consideraría parte del rol de un servicio VPN. Además siguen agregando funciones, así que me parece una opción bastante interesante y competitiva. Más bien me sorprende lo mucho que ofrecen en el tier barato, por eso me intriga más esa evaluación
    • Entonces puedes instalar headscale y alojarlo tú mismo para usarlo sin costo
      También hay productos competidores que se solapan en parte con Tailscale, aunque quizá no encajen exactamente con lo que quieres
      De todos modos, en cuestión de minutos varias partes del proyecto empezaron a encajar mucho mejor que antes
      Para lo que hace, es una de esas herramientas raramente simples, y el tier gratuito también es bastante generoso, con 100 dispositivos y 3 usuarios
    • A nosotros nos resultó muy fácil convencer. Salimos de una configuración con OpenVPN, y gracias a Tailscale se volvió mucho más fácil hacer el onboarding de nuevos empleados y varias otras cosas de la manera correcta. Es aún más importante porque somos una empresa totalmente remota
      Claro, por mi rol tenía bastante influencia para convencer a la gerencia en estos temas, pero el precio no fue un problema
      Somos clientes satisfechos desde abril del año pasado y todos usamos el tier premium, es decir, el caro. La velocidad de desarrollo también es impresionante. Algunas funciones que dijeron que podían tardar años ya salieron el año pasado
      Cloudflare One también pudo haber sido una alternativa, pero habría sido más caro
    • No sé qué gerencia se va a trabar por 18 dólares al mes. Visto como costo por persona, es casi cero comparado con decenas de cosas que se compran para un empleado
    • Ese fue el motivo clave que nos empujó hacia Twingate. Después de usarlo, terminé prefiriendo un poco más las funciones de enrutamiento de Twingate. No significa que odie Tailscale; usamos ambos según el caso

  • Me pregunto qué proveedor usan para el sitio web. Casi todos los demás proveedores tienen soporte para IPv6, así que suena raro que tengan que hacer tantos rodeos por IPv6

    • Según el resultado de $ host www.tailscale.com, la dirección IPv4 76.76.21.21 de www.tailscale.com es de Vercel, y las direcciones IPv6 son de Amazon
      IPv4 usa un certificado de Let’s Encrypt, e IPv6 usa un certificado de Amazon

  • En verdad da envidia que tengan un CI/CD y monitoreo tan sólidos como para confiar en hacer un despliegue masivo en diciembre. Su cultura de ingeniería se ve bastante fuerte.
    Aun así, todavía hay preguntas sin responder. Si la configuración de IPv6 rompió la renovación automática del certificado de IPv4, me pregunto por qué no les pasó mucho antes. También me pregunto por qué tardaron 90 minutos en resolver la caída. Es una publicación de blog y no un postmortem real, pero habría estado bien tener aunque fuera una cronología breve.
    También me pregunto por qué no se mudan a un proveedor de DNS que soporte IPv6 de forma nativa. Me pregunto si vale la pena la carga operativa de tener dominios separados para scripts o paquetes. Excluyendo terceros como repositorios de paquetes, me pregunto si otros también lo hacen así.

    • Según entiendo, parece que cambiaron a la configuración actual 90 días antes de la caída. El certificado inicial instalado durante la migración era de 90 días, así que la caída ocurrió 90 días después de la migración.
    • Ellos usan Vercel, y Vercel no tiene soporte para IPv6.

  • No entiendo por qué el proxy tenía que terminar TLS. Si hubiera sido simplemente un proxy TCP, al menos el monitoreo no habría asumido erróneamente que el certificado no estaba por expirar.
    Además, si estaban haciendo la validación del dominio con un desafío TLS-ALPN, un proxy TCP también podría haber permitido la renovación automática.

    • Un proxy TCP descarta la dirección IP del usuario, a menos que uses algo como el protocolo PROXY. Para eso, el servidor HTTPS de destino también tiene que soportarlo, y también necesitas una forma de impedir que usuarios no autorizados inyecten su propio encabezado PROXY.
      Si no necesitas para nada la IP del usuario, no es un problema, pero suele ser útil para logs y detección de abuso.
      https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
    • No es una gran razón, pero HTTP/3 no funciona sobre TCP, y operar un proxy UDP no parece algo muy divertido.
    • No hay necesidad de terminar TLS. Ese fue uno de nuestros errores y es un ítem de trabajo que vamos a corregir.
      Cuando descubrimos por primera vez que IPv6 estaba roto, levantamos un proxy a toda prisa, y quienes lo hicieron en ese momento no sabían cómo funcionaba ACME.
      Vamos a cambiarlo a un proxy TCP simple.
    • Un proxy que no termina TLS es bueno para montarlo en servicios como Hetzner. Si configuras bien CAA, le dejas al proveedor solo la latencia y la disponibilidad, y también puedes evitar servicios ridículamente caros como CloudFront o proxies basados en EC2.
      Por lo que veo, Tailscale parece usar NetActuate para pkgs.tailscale.com. Creo que NetActuate podría ayudar a ofrecer proxies no terminales en varias ubicaciones a un precio razonable. No hay precios en su sitio web, pero no parece una empresa que le meta un margen de 50 veces al tráfico saliente.
    • Es posible que hayan puesto AWS CloudFront CDN al frente para IPv6. Si hacen eso, CloudFront termina TLS, y hasta donde sé no es opcional.

  • Si una organización como Tailscale comete aunque sea un solo tropiezo en un área mínimamente relacionada con la seguridad, para alguien apenas paranoico como yo se siente demasiado riesgoso.
    Necesitan una mejor explicación sobre esta parte.

  • Ya que seguramente tienen monitoreo de infraestructura, basta con agregar 50 líneas de código que accedan a todos los dominios públicos por IPv4 e IPv6 y alerten si el certificado expira en menos de 19 días. La renovación automática se ejecuta 20 días antes y listo.
    Después de que en los inicios de una empresa pequeña se nos pasaran algunas renovaciones de SSL, escribí este código hace años, y desde entonces no tuvimos incidentes relacionados con SSL.
    No hace falta una invitación de calendario; la única corrección necesaria es esta. La parte clave es “actualizaremos la infraestructura del prober para verificar por separado los endpoints IPv4 e IPv6”.

  • Dice que “esa configuración era considerada una mala configuración por ese proveedor, por lo que recibimos advertencias continuamente desde que se desplegó”.
    Entonces, ¿recibieron advertencias relacionadas con el certificado durante 90 días y luego el certificado falló?

    • No parece que hayan recibido advertencias sobre el certificado durante 90 días, sino más bien advertencias relacionadas con DNS durante 90 días. Parece que el equipo de Tailscale no sabía antes del incidente que Vercel rechaza la renovación automática de certificados si existen registros DNS IPv6/AAAA.
      Como no vi la advertencia real, no sé si esa advertencia lo indicaba claramente.