Resumen

  • wolfSSL 5.9.2 corrigió una vulnerabilidad alta en compilaciones con RPK: una clave pública bruta no acordada podía sustituir a X.509 y evitar la validación de cadena. La corrección presume X.509 si no hubo otra negociación y rechaza la forma inesperada.
  • RFC 7250 no describe una versión incompleta de X.509. Define un tipo TLS explícito que transporta un solo SubjectPublicKeyInfo DER. CertificateVerify acredita posesión de la clave privada; no aporta por sí mismo nombre, emisor, vigencia ni rol.
  • La operación segura necesita dos controles enlazados: demostrar qué tipo se negoció y consultar una asociación externa, actual y acotada entre la SPKI y el servicio, dispositivo o función. El resultado de la aplicación llega después y no debe confundirse con esas pruebas.

El parser no tenía derecho a cambiar de constitución

La nota de la versión 5.9.2 de wolfSSL clasificó CVE-2026-55960 como alta. Con HAVE_RPK activado, el software podía aceptar una Raw Public Key que no había sido negociada. Al no existir cadena X.509 en esa entrada, el camino de análisis podía concluir sin la comprobación de confianza que habría correspondido al certificado esperado.

RPK no se activa por defecto en una compilación autónoma, aunque forma parte de --enable-all. El aviso no dice cuántos sistemas estuvieron expuestos, si hubo explotación ni cuál fue la primera versión afectada. Esas cifras no pueden deducirse. Sí puede observarse el error de autoridad: la representación enviada por el atacante consiguió seleccionar una rutina de validación menos exigente que la acordada por los pares.

La reparación fijó X.509 como expectativa cuando no existe una selección alternativa. En el cliente se compara el tipo recibido del servidor con el elegido; en el servidor se verifica del mismo modo la credencial del cliente. Una diferencia termina en UNSUPPORTED_CERTIFICATE. PR 10702 documenta además pruebas de regresión para ambas direcciones.

No es un detalle sintáctico. Una biblioteca puede saber leer SPKI y X.509, pero esa capacidad no le otorga permiso para escoger entre sus modelos de confianza. El orden correcto es político y técnico: negociar el régimen, comprobar que llegó la forma autorizada y después ejecutar su verificador.

Lo que viaja en una RPK

RFC 7250 asigna el valor 2 a Raw Public Key y crea dos extensiones: una para los tipos de credencial del cliente y otra para los del servidor. Las listas indican lo que cada extremo puede presentar o procesar. El servidor elige una opción común; si no existe, la conexión debe fracasar.

Una vez elegida RPK, Certificate contiene una única estructura DER SubjectPublicKeyInfo: identificador de algoritmo, parámetros si corresponden y bits de la clave. No hay una cadena escondida ni un certificado autofirmado implícito.

RFC 8446 conserva esa forma en TLS 1.3. Su CertificateType incluye RawPublicKey(2) y limita certificate_list a una entrada SPKI cuando se negoció. También deja claro el punto de partida: el tipo del certificado es X.509v3 salvo negociación expresa en contrario.

Por eso una RPK debe recibir un trato doblemente preciso. Si fue seleccionada, exigirle una cadena X.509 contradice el acuerdo. Si no fue seleccionada, admitirla porque la SPKI tiene buena estructura contradice el mismo acuerdo. El formato y la autorización del formato son hechos diferentes.

Posesión, identidad y permiso son tres verbos

En TLS 1.3, CertificateVerify firma el transcript y demuestra control de la clave privada correspondiente. Finished confirma que las partes comparten el estado correcto del handshake. La conexión puede así establecer posesión criptográfica con garantías fuertes.

Pero la SPKI no dice a quién pertenece ese control. RFC 5280 señala la diferencia: una autoridad certificadora firma la unión entre material de clave y sujeto. El cuerpo del certificado incluye emisor, sujeto, serie, intervalo de validez y extensiones. El cliente todavía debe validar ruta, nombre, uso y política; X.509 tampoco es una autorización de negocio. Sin embargo, esas afirmaciones ni siquiera están presentes en la clave bruta.

RFC 7250 exige que otro mecanismo vincule la clave con la entidad y que el software consulte el estado de ese vínculo. La segunda condición suele perderse en diseños que guardan una huella y la llaman “pin”. Una coincidencia histórica no responde si la clave fue retirada, reasignada, comprometida o reemplazada.

El registro externo debería identificar sujeto y función, ámbito de host y servicio, SPKI exacta, propietario de la asignación, comienzo y fin, generaciones anterior y siguiente, canal de distribución y estado de revocación. También debe indicar qué consumidores ya aplican la versión nueva y cuáles siguen aceptando la antigua.

El código de biblioteca revela las piezas que faltan

wolfSSL pide habilitar RPK, configurar preferencias de tipo y entregar un callback para autenticar la clave fuera de TLS. Su ejemplo interoperable con GnuTLS completa TLS 1.3, pero informa que el certificado del par no fue verificado hasta que la aplicación aporta esa lógica. El cifrado funciona antes de que exista una decisión de identidad.

GnuTLS ofrece otra vista: puede buscar una clave almacenada por host y servicio, distinguir “no existe” de “existe pero no coincide”, aplicar caducidad y delegar el almacenamiento. Es una plantilla útil para el registro, aunque no sabe por sí sola quién autorizó la entrada inicial o qué privilegio debe abrir.

La existencia de estas API evita una excusa: la responsabilidad exterior no es una abstracción académica. Hay una llamada que debe ejecutarse, un resultado que debe conservarse y un fallo que debe cerrar el paso. Aun así, tener el flag, la función o el callback no demuestra que la producción los haya usado.

DANE y firmware: dos relojes para la misma obligación

DANE puede ser la autoridad externa. RFC 6698 define registros TLSA protegidos por DNSSEC y permite seleccionar SPKI, completa o mediante hash. Un nombre de servicio queda asociado a material criptográfico sin depender necesariamente de la cadena pública tradicional.

La autoridad se realiza solo si el cliente valida DNSSEC, interpreta correctamente uso, selector y tipo de coincidencia, y compara el objeto correcto. Publicar TLSA no obliga a ningún cliente a consultarlo.

RFC 7671 convierte la rotación en una secuencia: publicar con antelación la asociación nueva, esperar la expiración de cachés, desplegar la clave o certificado y retirar luego los valores obsoletos. Durante el cambio hay más de una vista válida del mundo. El inventario debe conocer la generación que observa cada verificador.

RFC 7925 coloca el mismo problema en dispositivos restringidos. La clave del servidor o su hash suele distribuirse antes del primer intercambio. RPK reduce bytes y complejidad de certificado, pero un dispositivo con vida larga sigue necesitando un canal seguro de actualización. En ese entorno, revocar significa alcanzar firmware, almacenamiento local y equipos desconectados; no basta con alterar un registro central.

El expediente mínimo de una aceptación

Una operación defendible conserva siete campos lógicos. Política configurada: qué tipos se permiten para cada rol. Oferta: qué valores salieron en ClientHello. Selección: qué tipo quedó acordado. Forma: qué objeto llegó. Posesión: si la firma y Finished pasaron. Identidad: qué fuente externa, versión y fecha unieron la SPKI al rol. Autorización: qué acción concreta permitió la aplicación.

El indicador “TLS exitoso” solo describe el desenlace. Podría ocultar una RPK no negociada, una asociación antigua, un callback omitido o un rol demasiado amplio. Un rechazo de certificado, en cambio, puede demostrar que la frontera está funcionando.

La primacía del código en ejecución de Heng Lu sirve aquí como criterio de evidencia. El RFC define el contrato, IANA numera las extensiones y un registro exterior publica una pretensión. La soberanía práctica de la aceptación reside en el proceso que rechaza la forma incorrecta, consulta la asociación vigente y limita el permiso. El parche de wolfSSL cambió ese acto final.

Límites

No hay base para atribuir explotación ni cuantificar despliegues afectados. Tampoco para declarar insegura toda RPK. Una clave bruta negociada y bien vinculada puede ser adecuada para redes cerradas o dispositivos limitados; un certificado X.509 mal validado también puede fallar.

La enseñanza no consiste en preferir siempre un contenedor. Consiste en impedir que una credencial use el camino de aceptación de otra sin cumplir sus reglas.

Sources