Spotify sufrió ayer un ataque global debido a -lo has adivinado- un archivo SSL/TLS caducado. Parece que cada mes (incluso cada semana) es un enjabonar, enjuagar y repetir.
Interrupciones causadas por expirado SSL/TLS certificados ocurren mucho más a menudo de lo que aparece en los titulares, y pueden pueden manifestarse de muy diversas maneras.
A principios de este año, Microsoft Teams failed renovar a certificado de autenticación de clientedejando millones de usuarios bloqueados al empezar a trabajar desde casa. La semana pasada en California, un certificado caducado causó subnotificación de casos de COVID-19.
En este caso, los usuarios de Spotify no pudieron acceder a al popular servicio de música en streaming, y miles de ellos (unas 4.000 conversaciones) acudieron a twitter utilizando el hashtag #spotifydown - todo debido a un certificado caducado.
No eres solo tú, @Spotify está caído para todos. #SpotifyDown pic.twitter.com/dlreaqeQW7
- Johnny Blasé (@vorpalblaze) Agosto 19, 2020
Todo lo que hace falta es uno
La mayoría de las organizaciones tienen decenas o incluso cientos de miles de estos SSL/TLS certificados en su entorno. Mantener el ritmo de emisión emisión y renovaciones a esta escala cualquier cosa menos fácilespecialmente teniendo en cuenta que la mayoría de los equipos de métodos manuales para rastrearlos.
Basta con que se produzca un vencimiento inesperado para que tenga que arreglar una costosa avería. Sin embargo, algunos líos son más difíciles de solucionar que otros. de limpiar que otros. Esto se debe porque los certificados no sólo hay que renovarlos, también a menudo necesitan actualizarse en múltiples servidores web, servidores de aplicaciones y otras ubicaciones de la red que dependen de ellos.
Si existe un certificado existe en varias ubicaciones, es fácil olvidar dónde debe instalarse. instalarse. Esto resulta especialmente problemático con certificados comodín.
Parece que @Spotify olvidó renovar su certificado TLS 🙁 *.wg.spotify.com #ssl #cert https://t.co/wclmzVMpTJ pic.twitter.com/rRzFHPeuEE
- Louis (@lpoinsig) Agosto 19, 2020
Certificados comodín: Un arma de doble filo
Los certificados SSL/TLS se utilizan habitualmente para verificar la confianza entre los sitios web de acceso público y el navegador web de su dispositivo. En términos sencillos, si visita un sitio web con un certificado SSL/TLS, la dirección comenzará con «https://» en lugar de «http:// » (la s significa seguro). Cada uno de estos certificados tiene una fecha de caducidad, momento en el que deben ser actualizados y reemplazados.
La mayoría de las empresas no tienen un único sitio web, sino múltiples dominios y subdominios (por ejemplo, keyfactor.com, info.keyfactor.com, blog.keyfactor.com, etc.). Por ello, algunas organizaciones, o ciertos grupos dentro de ellas, optan por utilizar certificados wildcard.
En lugar de adquirir múltiples certificados SSL/TLS de una autoridad de certificación (CA) pública para cada subdominio, se puede utilizar un único certificado wildcard para proteger un sitio web y todos sus subdominios. Esto puede resultar conveniente, ya que se necesita registrar un menor número de certificados para su infraestructura.
Sin embargo, es un arma de doble filo, porque sin una gestión adecuada del ciclo de vida de los certificados, puede ser difícil saber si se ha reemplazado el certificado en todas las ubicaciones donde necesita ser actualizado, y todo al mismo tiempo. También genera problemas de seguridad, ya que un único certificado wildcard podría poner en riesgo su infraestructura completa si se ve comprometido.
En la mayoría de los casos, recomendamos no utilizar certificados wildcard, simplemente por el elevado riesgo de interrupción o brecha que podrían generar.
Un ejemplo: Spotify
Volviendo a Spotify. Una rápida consulta a los Google Certificate Transparency Logs (véase la imagen siguiente) muestra que el certificado particular que causó esta interrupción era, de hecho, un certificado wildcard. ¿Cómo saberlo? El asterisco junto al nombre de dominio (CN=) es lo que lo delata.
Recomendaciones
Para evitar esta situación por completo, debe limitar el uso de certificados wildcard en su organización. Dicho esto, hay ciertas situaciones en las que pueden ser beneficiosos. De cualquier manera, deberá asegurarse de tener visibilidad de cada certificado en su organización y contar con procesos para renovarlos antes de que caduquen.
A continuación, se presentan algunas conclusiones clave:
- Limite el uso de certificados wildcard en su organización
- Mantenga un inventario preciso y actualizado de los certificados en su entorno, incluyendo (como mínimo) la longitud de la clave, el algoritmo hash, la caducidad, las ubicaciones, y el propietario del certificado
- Asegúrese de que las claves privadas se almacenen y protejan de acuerdo con las mejores prácticas
- Automatice la renovación y el aprovisionamiento de certificados para evitar caducidades inesperadas
No es ningún secreto que las herramientas de automatización del ciclo de vida de los certificados, como Keyfactor Command están diseñadas para satisfacer estas necesidades (y más). El rápido crecimiento del número de claves y certificados en las organizaciones ha dejado obsoletos los métodos manuales y desarrollados internamente. Sin embargo, antes de buscar herramientas, es importante definir sus requisitos.
¿Cuál es su nivel de madurez?
Si no está seguro de por dónde empezar, identificar su situación actual es un buen punto de partida.
Descargue el Modelo de Madurez de la Gestión de Certificados para ver cómo se compara su organización con las mejores prácticas y obtener recomendaciones prácticas para mejorar sus procesos.
