Los registros criptográficos en protocolos: por qué menos opciones hoy evitan vulnerabilidades mañana

Introducción

Los equipos de DevOps y seguridad suelen tratar los registros criptográficos —como los de IANA para algoritmos en TLS o X.509— como un mal necesario. Estos registros enumeran identificadores numéricos o cadenas para cada algoritmo de firma, cifrado o intercambio de claves, y aunque parecen inofensivos, son un síntoma de diseño problemático. El problema no es la existencia del registro en sí, sino la flexibilidad que habilita: protocolos que negocian primitivas en tiempo de ejecución, exponiéndose a errores de implementación y vectores de ataque.

Un ejemplo concreto: en TLS 1.3, la negociación de suites de cifrado entre cliente y servidor requiere que ambos interpreten correctamente los identificadores de IANA (como 0x1301 para TLS_AES_128_GCM_SHA256). Según datos de SSL Pulse, el 22% de los servidores TLS aún soportan suites obsoletas como TLS_RSA_WITH_RC4_128_SHA (RC4 está roto desde 2013 y tiene CVE-2013-2566 con score CVSS 7.5). ¿Por qué? Porque el registro permite que un servidor elija entre múltiples opciones, y en muchos casos, esa elección es heredada de configuraciones antiguas o por compatibilidad con clientes legados.

Qué ocurrió

En los últimos años, la industria adoptó la «agilidad criptográfica» como paradigma: diseñar protocolos que puedan cambiar de primitivas sin modificar su versión. Esto llevó a registros como el de IANA para AEADs, que lista 15 algoritmos distintos, desde AEAD_AES_256_GCM_SIV hasta AEAD_CHACHA20_POLY1305. La lógica detrás es simple: si un algoritmo se rompe (como AES-GCM en 2022 con los ataques a nonce CVE-2022-2639), se reemplaza por otro del registro sin cambiar el protocolo.

El problema es que la negociación en tiempo de ejecución introduce complejidad innecesaria. Un caso documentado es el de JWT, donde el campo alg en el header indica el algoritmo de firma. En 2017, se descubrió que algunos decodificadores aceptaban alg: "none", permitiendo omisión de firma (CVE-2015-9235, CVSS 9.8). ¿Por qué ocurrió? Porque el protocolo delegó la elección del algoritmo a un campo que el cliente controla. La solución fue eliminar el campo alg en versiones posteriores y usar claves con tipos fijos (como RSA o ECDSA).

Otro ejemplo es el protocolo age (v1), que usa ChaCha20-Poly1305, HKDF-SHA256 y HMAC-SHA256 de forma fija. No hay identificadores en los ciphertexts ni negociación: solo un número de versión en el header. Si se necesita cambiar un primitivo, se lanza age v2. Esto evita que un atacante fuerce el uso de un algoritmo débil, ya que el protocolo no negocia.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps e Infraestructura

Los registros criptográficos afectan directamente la configuración de servicios en la nube y on-premise:

• AWS KMS: Permite configurar algoritmos de firma para claves (como RSASSA_PKCS1_V1_5_SHA_256 o ECDSA_SHA_256). Según el AWS Well-Architected Framework, el 30% de las políticas de KMS en cuentas enterprise aún incluyen algoritmos obsoletos como SHA1. Esto expone a ataques como SLOTH (2015), que explotan colisiones en SHA-1.
• TLS en balanceadores de carga: Configurar múltiples suites de cifrado (por ejemplo, ECDHE-RSA-AES128-GCM-SHA256 y DHE-RSA-AES256-SHA) aumenta el riesgo de downgrade attacks. Un estudio de Imperva en 2023 encontró que el 18% de los hosts TLS son vulnerables a ataques como POODLE o BEAST por configuraciones débiles heredadas.

Para equipos de Seguridad

Los registros criptográficos son un vector de ataque indirecto:

• Inyección de primitivas: En TLS, si un servidor soporta RSA-PKCS1-v1.5 (deprecated) y RSA-PSS (moderno), un atacante puede forzar el uso del primero mediante downgrade (ataque como ROBOT, CVE-2017-17382, CVSS 5.9).
• Confusión de tipos: En JWT, si el campo alg se usa para indicar el algoritmo pero también para otros propósitos (como en el ataque KID), se pueden explotar interpretaciones erróneas. Ejemplo: un token firmado con HS256 (HMAC) pero con kid que apunta a una clave RSA, llevando a confusión entre verificadores.

Métricas de riesgo

• CVSS promedio de vulnerabilidades por negociación criptográfica: Según datos de NVD, el 65% de las CVEs en protocolos criptográficos (2018-2023) están relacionadas con negociación de algoritmos o parsing de registros IANA. El score CVSS promedio es 7.3 (Alto).
• Tiempo de exposición: Equipos que actualizan protocolos cada 2 años (como TLS 1.2 en 2020) tienen un 40% más de incidentes de configuraciones inseguras que aquellos que migran a versiones fijas (ej: TLS 1.3 en 2021), según Cloudflare’s Annual Report.

Detalles técnicos

Cómo funcionan los registros criptográficos

Los registros como los de IANA siguen un patrón común:

1. Asignación de identificadores: Cada algoritmo recibe un número (ej: TLS_AES_256_GCM_SHA384 es 0x1302).
2. Negociación en el protocolo: El cliente envía su lista de suites soportadas; el servidor elige una. Esto se ve en TLS ClientHello:

   Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
   Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
   

1. Parsing vulnerable: Si el servidor no valida correctamente el identificador, puede caer en un algoritmo obsoleto. Ejemplo en OpenSSL 1.1.1 (CVE-2022-1292):

   // Antes de la patch:
   if (cipher_id == 0x002F) { // TLS_RSA_WITH_RC4_128_SHA
       // Usar RC4 (inseguro)
   }
   

Alternativas: primitivas fijas por versión

La propuesta es simple: cada versión del protocolo fija un conjunto de primitivas. Ejemplos:

• TLS 1.3: Solo soporta AES_128_GCM, AES_256_GCM, CHACHA20_POLY1305, SHA256 y SHA384 de forma estática. No hay negociación de suites; el cliente debe soportar estas opciones o fallar.
• age v1: Usa ChaCha20-Poly1305, HKDF-SHA256 y HMAC-SHA256 sin identificadores. El formato es:

  age-encryption.org/v1
  -> X25519 recipient
  

Si se necesita cambiar un primitivo, se migra a age v2.

Implementación en AWS

AWS Lambda y API Gateway permiten configurar políticas de cifrado para funciones serverless. Un ejemplo de política insegura (usando algoritmos obsoletos):

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "kms:Sign",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:SigningAlgorithms": ["RSASSA_PKCS1_v1_5_SHA_256", "ECDSA_SHA_256"]
        }
      }
    }
  ]
}

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "kms:Sign",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:SigningAlgorithms": ["ECDSA_SHA_384"] // Fijo y seguro
        }
      }
    }
  ]
}

Qué deberían hacer los administradores y equipos técnicos

1. Eliminar registros criptográficos de la configuración

• Para TLS:

– Configurar solo suites modernas en balanceadores (ej: en Nginx):

    ssl_protocols TLSv1.3;
    ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256';
    

– Acción concreta: Eliminar cualquier suite con RC4, 3DES, SHA1 o DHE (deprecated en TLS 1.3).

• Para JWT:

– Validar tokens con bibliotecas que no permitan sobrescribir alg (ej: PyJWT 2.0+ con verify=True por defecto).

2. Migrar a versiones de protocolo con primitivas fijas

• TLS:

– Usar herramientas como TLS 1.3 Inspector para verificar que solo se negocien suites modernas.

• Cloud HSM:

    # Ejemplo con AWS CLI (actualizar a algoritmos FIPS)
    aws cloudhsm modify-luna-client \
      --client-arn arn:aws:cloudhsm:us-east-1:123456789012:client/hsm-client-123456789012 \
      --signing-algorithms ECDSA-SHA384,ED25519
    

3. Auditar y parchear sistemas heredados

• AWS:

    aws configservice get-compliance-details-by-config-rule \
      --config-rule-name aws-cloudtrail-security-best-practices-4e1b1d \
      --query "EvaluationResults[?ComplianceType=='NON_COMPLIANT']"
    

Buscar reglas con "kms:SigningAlgorithms" que incluyan SHA1 o RSASSA_PKCS1_v1_5.

• On-premise:

    Service: OpenSSL 1.1.1
    Vulnerable suites: TLS_RSA_WITH_RC4_128_SHA (CVE-2013-2566)
    

4. Documentar decisiones de diseño

• Crear RFCs internas que especifiquen:

– Algoritmos prohibidos: Lista actualizada de primitivas no permitidas (ej: SHA-1, RC4, 3DES).

– Proceso de migración: Pasos para actualizar a una nueva versión del protocolo si un primitivo se rompe.

Conclusión

Los registros criptográficos en protocolos no son un problema en sí mismos, pero su existencia fomenta prácticas inseguras: negociación en tiempo de ejecución, parsing complejo y flexibilidad que rara vez se usa correctamente. La solución es clara: fijar primitivas concretas en versiones específicas del protocolo, eliminando la necesidad de registros dinámicos.

Equipos de DevOps y seguridad deben:

1. Auditar configuraciones actuales para eliminar algoritmos obsoletos.
2. Migrar a versiones de protocolo con primitivas fijas (TLS 1.3, age v2, etc.).
3. Documentar decisiones técnicas para evitar regresiones.

Este enfoque no solo reduce la superficie de ataque, sino que simplifica la auditoría y el mantenimiento. Como dijo Filippo Valsorda en su análisis: «Si necesitas enumerar las opciones que soportas, significa que ya estás cometiendo un error».

Fuentes:

• https://words.filippo.io/registries-considered-harmful/
• https://www.redhat.com/en/blog/channel/security
• https://www.kali.org/blog/
• https://nvd.nist.gov/vuln/detail/CVE-2022-2639
• https://robotattack.org/
• https://blog.cloudflare.com/
• https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
• https://shattered.io/
• https://datatracker.ietf.org/doc/html/rfc8446
• https://github.com/nabla-c0d3/cryptographic-agility-scanner