Resumen

  • SSLKEYLOGFILE reduce cada secreto a tres campos: etiqueta, valor aleatorio del ClientHello y secreto. La combinación con paquetes capturados y parámetros del handshake puede quitar la protección TLS; la línea no incluye hora, endpoint, identidad, permiso, procedencia ni custodia.
  • La capacidad no es meramente observacional. Puede abrir tráfico almacenado, habilitar inyección en conexiones activas, afectar autenticación derivada de exporters, anular forward secrecy y, con el secreto maestro de TLS 1.2, permitir formas más amplias de suplantación.
  • RFC 9850 limita el formato a sistemas donde TLS protege datos de prueba y prohíbe usarlo en producción. Que el descifrado funcione acredita una relación técnica entre material y registros, no quién actuó ni si la recolección fue lícita.

La cadena de custodia no cabe en tres campos

El analista ve una petición HTTP dentro de lo que antes era ruido cifrado. El hallazgo puede ser verdadero y útil. Pero el salto desde “estos bytes se descifraron” hasta “esta persona realizó esta acción” atraviesa decisiones que SSLKEYLOGFILE no registra.

Hace falta fijar de dónde salió la captura, qué interfaz la observó, qué filtro se aplicó, qué reloj la fechó y qué paquetes pudieron perderse. Hace falta identificar el proceso que emitió el secreto, el binario que incluía la capacidad, la forma de activación y la persona autorizada para usarla. Después hay que enlazar ambos objetos con hashes, almacenamiento y transferencias de custodia. La herramienta de análisis añade su propia versión, configuración y resultado reproducible.

Sin esos recibos, el archivo sigue siendo peligroso, pero no se convierte en testigo. Su poder criptográfico no rellena las casillas administrativas y humanas ausentes.

Normalizar una convención no inventarla

RFC 9850 se publicó en julio de 2026 como documento informativo de IETF. Sus autores son Martin Thomson, Yaroslav Rosomakho y Hannes Tschofenig. El propio texto atribuye el origen del formato a Network Security Services y dice que muchas personas lo hicieron evolucionar; los autores documentan el uso existente y lo amplían para Encrypted Client Hello.

El perfil oficial de IETF guardado el 1 de septiembre describe a Thomson como ingeniero en Mozilla, enumera 45 RFC y muestra responsabilidades vigentes en grupos de trabajo, revisión y enlace. Es un contexto sólido para su contribución a protocolos. No demuestra que inventara por sí solo el formato, que controle los binarios de terceros o que pueda autorizar la interceptación de una red.

IANA mantiene el registro de etiquetas SSLKEYLOGFILE. El registro hace que una etiqueta tenga un significado común entre implementaciones y herramientas. No legitima el uso operativo: RFC 9850 señala expresamente que la aprobación de expertos para una etiqueta no equivale a respaldarla.

Lo que transporta la línea

El primer valor, label, identifica la clase de secreto. El segundo, client_random, reproduce los 32 bytes Random del ClientHello y sirve para distinguir conexiones dentro de un archivo. El tercero lleva el secreto en hexadecimal.

De esta lista se deriva una conclusión estructural que debe presentarse como inferencia, no como cita: el formato no exige fecha, hostname, dirección, puerto, certificado, proceso, usuario, decisión de autorización, historial de acceso, referencia de captura ni cadena de custodia. El valor aleatorio puede correlacionar una conexión; no certifica que un equipo perteneciera a alguien o que un usuario estuviera detrás de ella.

La especificación también reconoce una insuficiencia técnica. Las líneas no anotan la suite criptográfica ni otros parámetros de conexión, de modo que puede necesitarse el registro del handshake. Por eso el archivo no es una transcripción autosuficiente. Es un insumo que necesita otra evidencia.

Una línea bien formada puede copiarse o construirse fuera del expediente. Esto no invalida los registros reales. Obliga a fundamentar la confianza en el procedimiento de adquisición y en la corroboración, no en la apariencia sintáctica.

Poder leer y poder escribir

Restar autoridad probatoria al archivo no reduce su impacto. La sección de seguridad de RFC 9850 advierte que el acceso puede romper confidencialidad e integridad tanto en conexiones activas como en registros cifrados almacenados.

Los secretos permiten derivar claves simétricas. En las circunstancias cubiertas, quien puede quitar la protección también puede cifrar datos para una conexión activa, con posibilidad de inyectar o modificar contenido. Un peritaje debe separar lo que observó de cualquier dato que su propia prueba activa haya creado.

Los exporters abren otra superficie. Una aplicación puede usarlos para vincular sesiones, autenticar o producir más secretos. La filtración puede afectar una relación de confianza superior aunque la captura de red parezca contener solamente datos.

Forward secrecy tampoco sobrevive a la grabación del material relevante. Su objetivo es impedir que una futura pérdida de claves duraderas reabra conversaciones antiguas. Si el secreto de tráfico ya está archivado, una captura almacenada puede descifrarse más tarde. La exposición depende entonces de dos inventarios: secretos y paquetes.

Las etiquetas importan. En TLS 1.3 separan material de handshake, aplicación, datos tempranos y exporter. La entrada CLIENT_RANDOM de TLS 1.2 contiene el secreto maestro, al que la RFC atribuye lectura, alteración, reanudación, suplantación de cualquiera de los extremos, inserción de renegociación y falsificación de Finished. ECH_SECRET puede revelar el ClientHello interior y el SNI protegido. Un contador genérico de archivos oculta diferencias críticas.

Producción no es un laboratorio con más controles

La declaración de aplicabilidad de RFC 9850 es categórica. El formato se destina a sistemas donde TLS protege solo datos de prueba y no debe utilizarse en producción. Para software compilado recomienda condicionar la compilación, de modo que el binario desplegado no pueda activarlo.

La recomendación define dónde debe tomarse la decisión. Quitar la función antes del despliegue impide que una variable de entorno, un script apresurado o un atacante con acceso al contexto de lanzamiento la enciendan. Los permisos de archivo son necesarios en pruebas, pero no corrigen que un binario de producción incluya una capacidad prohibida.

El riesgo suele entrar disfrazado de temporalidad. Se habilita para reproducir un fallo, se conserva “por si acaso”, se conecta a un colector y termina en backups. Años de capturas de red, guardadas por otra finalidad, pueden adquirir valor retrospectivo cuando aparece el archivo de claves.

Encontrar la capacidad en producción exige contención: identificar build y proceso, detener nuevas emisiones, restringir archivos y capturas, delimitar conexiones, revisar exporters y ECH, y conservar evidencia sin copiar los secretos a sistemas de tickets o mensajería.

El handshake conserva su propia autoridad

RFC 9846 describe TLS 1.3 como negociación de parámetros, autenticación de pares según el mecanismo escogido —la del cliente puede faltar— y establecimiento de claves compartidas. El protocolo de aplicación todavía debe decidir qué identidad espera y cómo interpreta certificados.

SSLKEYLOGFILE exporta productos del cálculo de claves. No repite la validación del certificado, no dice qué nombre se comprobó, no afirma que el cliente estuviera autenticado ni asigna una persona a un endpoint. Incluso con el handshake capturado, la identidad de referencia y la política de validación necesitan registro propio.

También conviene limitar el significado del fracaso. El descifrado puede fallar por escoger otra conexión, carecer del handshake, usar una fase de clave distinta, invertir direcciones, confundir el ClientHello interior y exterior o perder contexto de un protocolo integrado. Un resultado negativo no prueba falsificación.

RFC 9325 trata autenticación, confidencialidad e integridad como propiedades relacionadas pero separadas. Desactivar dos con material de diagnóstico no convierte al archivo en autoridad sobre la tercera.

Un registro describe; no manda

The Policy Mirror de Heng Lu separa el registro que describe de la autoridad que pretende crear realidad. Running-Code Primacy limita el artefacto común a la función determinista que necesitan los sistemas en ejecución. On Reality Layers diferencia la capacidad ejecutable de la afirmación simbólica.

Aquí la capacidad ejecutable es intensa: los secretos correctos y los records correctos permiten ver o alterar tráfico. La afirmación simbólica excesiva es llamar al archivo “prueba de la sesión” sin procedencia, autorización ni custodia.

La contribución de Thomson y sus coautores se aprecia al mantener esa frontera. El RFC y el registro IANA aportan interoperabilidad, no permiso. Los autores responden del documento; los implementadores, del código; los responsables de release, del binario; los operadores, del lanzamiento; y los investigadores, de la cadena probatoria.

Reconstruir sin sobreatribuir

Un expediente fiable registra antes de descifrar: identidad del build, mecanismo de activación, solicitante y autorización, proceso y activo, intervalo de captura, permisos, hashes, almacenamiento y cada transferencia.

La captura queda separada con interfaz, dirección, filtro, reloj, pérdida, handshake, tupla de transporte y hash. El análisis documenta la etiqueta, el ClientHello random, los parámetros recuperados, la herramienta, la versión, los records que autenticaron, los que no y cualquier acción activa.

La conclusión distingue claves de endpoint e identidad humana; texto recuperado y texto mostrado; petición observada y resultado de negocio; prueba autorizada e interceptación. Así el archivo conserva su enorme utilidad sin representar una historia que nunca contuvo.

Fuentes