Resumen

  • Muhammad Usama Sardar llevó a RIPE 93 su crítica de la atestación temprana dentro del intercambio TLS. En la ruta Intel TDX de Cocos AI, una prueba con un valor de sesión reutilizado o distinto superó una comprobación de laboratorio y se liberaron datos de aplicación.
  • Otro aviso de Cocos describe una ruta AMD SEV-SNP que podía aceptar una prueba ajena cuando faltaba el valor esperado. La versión 0.9.0 trasladó la atestación a después del intercambio; la carta del grupo IETF SEAT exige frescura por conexión.

Un portero puede revisar una credencial con toda solemnidad y dejar entrar al dueño equivocado. En el aviso Intel TDX de Cocos AI, la comparación que faltaba tiene nombre: el valor de frescura de la sesión actual no llegaba a la política que validaba la prueba del chip. El ensayo del fabricante aceptó una prueba externa con un reportData discordante o reutilizado. Tras terminar el intercambio TLS, salieron bytes de aplicación.

La escena explica la pregunta que Muhammad Usama Sardar planteó el 27 de octubre en RIPE 93: ¿qué gana el protocolo metiendo la atestación dentro del saludo inicial si aumenta la complejidad de demostrar a quién pertenece la prueba? Su argumento encuentra aquí una condición de software concreta. El saludo y la verificación pueden terminar sin que ambos hayan hablado de la misma sesión.

La segunda alerta separa aún mejor el fallo de la consigna. Cocos AI documentó que su ruta AMD SEV-SNP en la versión 0.8.2 solo configuraba el ReportData esperado si el llamante entregaba un valor no vacío. Si lo omitía, podía aceptarse una prueba ajena a esa conexión; si lo enviaba, los valores discrepantes se rechazaban. La empresa pasó a la atestación posterior al intercambio en la versión 0.9.0.

Edgeless Systems describió otra avería en Contrast: antes de 1.16.0, bajo las condiciones de interceptación y falsificación o extracción de secretos que detalla su aviso, un informe válido de otra máquina podía ser suficiente. Su respuesta incluyó listas de identificadores de hardware permitidos. La cuestión común no es el brillo del sello, sino la identidad exacta de la máquina y de la conversación que autoriza.

La carta aprobada del grupo IETF SEAT exige vincular prueba y conexión TLS, admitir frescura por conexión y analizar formalmente el diseño mientras se redacta. Ese mandato puede ponerse a prueba: presentar un informe viejo, retirar el valor esperado y cambiar de máquina. Un protocolo que guarda los datos hasta que pasan esas pruebas merece el cartel de «confiable».