Resumen

  • RFC 9850 define la línea label client_random secret para sistemas en los que TLS protege solo datos de prueba; es Informational y prohíbe usar el mecanismo en producción.
  • Un secreto maestro de TLS 1.2, un secreto de tráfico TLS 1.3, un exporter y ECH_SECRET confieren capacidades distintas; “clave de depuración” no es una categoría de riesgo suficiente.
  • La validez sintáctica no acredita permiso. Habilitación, carga de trabajo, captura asociada, consumidores, almacenamiento, transporte, retención, destrucción y vuelta a conexiones no registradas necesitan recibos distintos.

Descifrar para diagnosticar no es un acto neutral. Un extremo TLS exporta información privada para que otro programa pueda retirar la protección de los registros. RFC 9850 aporta una gramática interoperable a ese acto. Precisamente por eso hay que separar el valor de la gramática del poder que pasa a manos del consumidor.

La especificación lo delimita con claridad. Publicada en julio de 2026 como RFC Informational, no pertenece al Standards Track. El formato está destinado a sistemas donde TLS solo protege datos de prueba y el mecanismo no debe emplearse en producción. Para software compilado, el texto considera preferible excluir la capacidad mediante compilación condicional. No es una invitación a activar un observador en servicios reales; es una convención diagnóstica bajo una frontera estricta.

Cada línea útil contiene tres valores separados por un espacio. label identifica el tipo de material. client_random reproduce los 32 bytes del Random del ClientHello en 64 caracteres hexadecimales y permite distinguir conexiones. secret contiene el valor hexadecimal con longitud dependiente del label. Los lectores aceptan CRLF, CR o LF y ambas cajas para las letras hexadecimales. Incluso pueden omitir líneas malformadas para recuperar secretos válidos de un archivo dañado.

Esa robustez explica lo que el parser sí puede afirmar: encontró material utilizable. No puede afirmar que el archivo sea completo, que la recogida estuviera autorizada, que la carga fuera de prueba, que el plazo siga abierto o que quien lo lee tenga permiso. En los tres campos no hay aprobador, entorno, productor, ticket, consumidor, caducidad ni resultado de borrado. Que una línea sea interpretable no convierte posesión en mandato.

Tampoco client_random completa la unión probatoria. El RFC advierte que el archivo no anota cipher suite u otros parámetros, por lo que puede hacer falta el registro del handshake. Una captura y su key log deben compartir un caso, una ventana y una carga de trabajo verificables. La captura sin secreto puede no ser legible; el secreto sin captura aprobada puede conservar capacidad sobre una conexión activa. Su proximidad en un directorio no prueba procedencia ni autorización comunes.

Los labels de TLS 1.3 reparten el poder por fase y dirección: tráfico temprano, handshake, tráfico de aplicación del cliente o servidor y exporters. La necesidad de inspeccionar una dirección después del handshake no autoriza por defecto los secretos tempranos, del lado opuesto o del plano de aplicación. La minimización empieza por el label, no por el tamaño del fichero.

TLS 1.2 plantea una autoridad mayor. CLIENT_RANDOM identifica el secreto maestro. RFC 9850 señala que puede permitir lectura y alteración, reanudación de sesión, suplantación de cualquiera de los extremos, inserción de registros que provoquen renegociación y falsificación de Finished. El propio texto propone no registrar ese valor para evitar esos riesgos. Agruparlo con un secreto de tráfico direccional de TLS 1.3 borra una diferencia decisiva.

Los exporters atraviesan la frontera del descifrado. Protocolos de aplicación pueden usarlos para vincular sesiones, autenticar o derivar otros secretos. Por ello, RFC 9850 contempla omitirlos en contextos de abuso posible o exigir autorización separada. El equipo que puede leer una captura no adquiere automáticamente el derecho a recibir material que sostiene una identidad de aplicación.

ECH protege otro objeto: el ClientHello interno. ECH_SECRET es el secreto compartido KEM de HPKE; ECH_CONFIG conserva la configuración empleada. Obtener ECH_SECRET permite revelar el ClientHello interno, incluido SNI. Tras ECH aceptado, los labels TLS 1.3 ordinarios se correlacionan con el Random interno, pero los labels ECH siempre con el externo. Una sola columna llamada “conexión” puede ocultar qué identidad estaba realmente protegida.

La capacidad no es necesariamente pasiva. Las claves de registro derivadas son simétricas; un poseedor puede llegar a cifrar para una conexión activa e inyectar o modificar datos. Además, registrar material elimina la garantía de forward secrecy de las conexiones incluidas. Quien consiga el fichero después puede descifrar records guardados antes. El límite operativo debe nombrar el conjunto exacto afectado.

La autorización empieza en el lanzamiento. Una variable como SSLKEYLOGFILE vincula la capacidad al contexto que inicia la aplicación. Un archivo especial puede evitar persistencia, pero crea una tubería hacia otro consumidor. El recibo de habilitación debe identificar carga de prueba, proceso o build, labels admitidos, aprobador, comienzo y final. El acceso técnico al contexto de lanzamiento no sustituye la autoridad organizativa.

Después viene la custodia: consumidores por función, accesos, transferencias con origen, destino, integridad, protección y caducidad; almacenamiento con permisos y retención; captura y secretos unidos por el caso sin repartir ambos a la misma audiencia por comodidad. La finalidad no es burocratizar el laboratorio, sino evitar una ruta invisible de escalada de privilegios.

El cierre tampoco cabe en un único delete. Herramientas, temporales, adjuntos, respaldos o memoria pueden contener copias. No se afirma que existan siempre; se exige enumerar los nodos posibles y registrar su disposición. El recibo de desmontaje reúne desactivación, cese del productor, salida de consumidores, destrucción de copias conocidas, expiración de transferencias y cierre de captura.

Las conexiones ya registradas no recuperan retrospectivamente su forward secrecy. La vuelta demostrable es prospectiva: nuevas conexiones usan secretos frescos no exportados, la superficie de logging dejó de producir y la aplicación supera una comprobación controlada sin ese canal. IANA estabiliza los nombres de los labels. Es coordinación útil y mínima: hace que el poder sea legible, no que su ejercicio sea legítimo.

Fuentes