Cuando la gente pierde las llaves o se compra una casa nueva, cambia las cerraduras y pasa a utilizar una llave nueva. Del mismo modo, cuando los operadores de sitios web pierden sus claves criptográficas o compran un nuevo nombre de dominio, adquieren un nuevo certificado web (un certificado de seguridad de la capa de transporte (TLS)) para evitar la suplantación de su dominio y la interceptación de sus conexiones cifradas HTTP sobre TLS (HTTPS).
Sin embargo, a diferencia de la sustitución de cerraduras y llaves físicas, las claves criptográficas repudiadas suelen seguir funcionando. Esta entrada del blog analiza por qué ocurre esto y cómo puede dar lugar a posibles problemas de seguridad.
Certificados TLS obsoletos: Un problema de caché
Para obtener un certificado TLS, el operador de un sitio web debe demostrar a una autoridad de certificación (CA) que controla el servidor web de su dominio mediante un intercambio de desafío-respuesta.
Una vez establecido el control, la CA emite un certificado TLS firmado que vincula el nombre de dominio del servidor web a su clave criptográfica pública. Para evitar la constante re-verificación del control del servidor web, a los certificados se les asigna un periodo de validez o duración de caché que indica cuánto tiempo es válido el mapeo dominio-clave.
Si el periodo de validez del certificado es demasiado corto, las CA incurren en costes operativos adicionales por volver a verificar el control del servidor web y volver a emitir certificados. Si es demasiado largo, un certificado puede anquilosarse -dejando de representar la correspondencia dominio-clave del mundo real- y permitir a un adversario hacerse pasar por el dominio de otra persona.
Descubra cómo tecnologías habilitadoras tan populares como TLS1.3, DNSSEC y HTTP/3 se están convirtiendo en globales.
Suplantación de sitios web HTTPS
Echemos un vistazo a HTTPS, el principal protocolo de seguridad de la Web, para entender cómo los certificados obsoletos pueden ser problemáticos. HTTPS utiliza certificados TLS para autenticar servidores web y detectar cuando terceros intentan falsificar un sitio web. En otras palabras, sólo el operador real de ejemplo.com debe ser reconocido por un navegador como https://example.com.
Los certificados obsoletos pueden romper la autenticación del servidor HTTPS al permitir a un tercero falsificar una conexión TLS para el dominio de otra persona. He aquí un ejemplo de cómo puede ocurrir:
- Mallory adquiere el dominio foo.com
- Mallory adquiere un certificado para foo. com válido durante un año.
- Mallory transfiere/vende inmediatamente el dominio a otra persona. Ahora Mallory puede hacerse pasar por foo.com mientras su certificado sea válido.
Mis colegas de la Universidad Estatal de Oregón, el Instituto de Tecnología de Georgia y la Universidad de Stanford y yo investigamos recientemente tres formas de anquilosamiento de terceros (véase nuestro artículo).
Hemos descubierto que, en los últimos diez años, más de 4 millones de dominios (más de 1.000 al día) tenían certificados de terceros caducados. Estos dominios comprenden dominios populares (61 en el Top 1K de sitios web de Alexa) e impopulares, y el número de certificados caducados ha crecido anualmente.
Aunque no pudimos deducir si estos dominios vulnerables fueron explotados activamente, la magnitud de la exposición pone de relieve la importancia de mitigar los certificados TLS obsoletos de terceros.
| Intervalo de fechas | # Certs / día | # Nombres de dominio completos/día | #Dominios de segundo nivel/día | |
|---|---|---|---|---|
| Compromiso clave | 2021-2023 | 493 | 787 | 347 |
| Cambio de propietario de dominio | 2013-2021 | 2,593 | 2,807 | 1,214 |
| Cambio de TLS gestionado | 2022 | 9,495 | 18,833 | 7,722 |
Posibles medidas paliativas
La forma aparentemente obvia de mitigar los certificados obsoletos es invalidarlos mediante la revocación. Sin embargo, esto tropieza con varios obstáculos:
- No todos los clientes HTTPS (por ejemplo, las utilidades de línea de comandos y las aplicaciones móviles) admiten la revocación.
- Algunos soportes de revocación tienen un alcance limitado (por ejemplo, Chrome/Chromium CRLSets) o conducen a fallos suaves, lo que hace que la revocación sea inútil contra un atacante que la intercepte.
- La revocación se utiliza poco porque es ineficaz y/o difícil de gestionar.
La coordinación con los participantes en TLS para superar estos retos podría reducir significativamente la prevalencia de certificados obsoletos. Pero una opción más accesible es acortar los periodos de validez de los certificados.
La comunidad de CA/navegadores ha ido avanzando en esta dirección: la duración máxima de los certificados se redujo a 825 días en 2017 y a 398 días en 2020. A pesar de esta mejora de la seguridad, los certificados de terceros obsoletos (y los dominios afectados) se han multiplicado desde 2017.
La reducción de la vida útil máxima a 90 días, que varias CA importantes (por ejemplo, Let’s Encrypt) ya aplican por sí mismas, podría eliminar hasta el 75% de la pérdida de vigencia de terceros.
Figura 2 – La reducción de la validez máxima de los certificados a 90 días eliminaría más del 75% de los casos de caducidad de terceros.
Desde una perspectiva más amplia, la causa principal de la caducidad de los certificados es el diseño actual de la autenticación de sitios web basada en certificados, que intenta tender un puente entre dominios independientes, servidores web y ciclos de vida de los certificados. Una solución más fundamental es disminuir la cadena de dependencia de la red entre los nombres de dominio y sus correspondientes claves criptográficas, reduciendo así las oportunidades de fractura de dependencia no intencionada o malintencionada.
Propuestas como la Autenticación de Entidades Nombradas Basada en DNS (DANE), la Red Centrada en el Contenido (CCN) y la Red de Datos Nombrados (NDN) alinean las claves criptográficas con la fuente autorizada de información de nombres, lo que da más poder a los operadores de nombres y minimiza los problemas de caché de autenticación.
Para saber más, lea nuestro artículo ‘Stale TLS Certificates‘.
Zane Ma es profesor adjunto en la Universidad Estatal de Oregón. Investiga la seguridad en Internet, centrándose en la autenticación de usuarios, clientes web y servidores.