Resumen

  • Content-Digest comprueba el contenido del mensaje y Repr-Digest los datos de la representación seleccionada. Una coincidencia no identifica a quien eligió esos bytes.
  • La traza fiable separa algoritmo, dominio de bytes, recálculo, firma, autoridad de la clave, vigencia, repetición, reglas de negocio y acción final.

La comprobación correcta produjo la decisión equivocada

Un atacante que controla el cuerpo y el campo de resumen no necesita romper SHA-256. Calcula el resumen de su propio contenido. El receptor puede repetir la operación y obtener el mismo resultado. Esa igualdad demuestra consistencia entre dos entradas del atacante, no confianza en el atacante.

El problema empieza cuando la interfaz reduce la conclusión a «verificado». ¿Qué fue verificado? No la cuenta, no el mandato y no la inocuidad del archivo. Sólo una relación entre una secuencia de bytes y un valor aceptado.

La telemetría debe usar predicados completos: content_digest_matched, signature_verified, key_authorized, freshness_validated. El sustantivo omitido suele ser el lugar donde se esconde la autoridad imaginaria.

RFC 9530 obliga a nombrar el objeto

Content-Digest se calcula sobre el contenido efectivo de un mensaje HTTP. Repr-Digest se calcula sobre todos los datos de la representación seleccionada. Compresión, rangos, métodos y metadatos pueden separar ambos dominios.

Una pasarela puede verificar el contenido codificado que recibió y una aplicación puede creer que quedó verificada la representación decodificada. Ambas afirmaciones serían localmente ciertas, pero no equivalentes. Antes de elegir el algoritmo hay que declarar qué bytes deben conservarse y en qué punto de la transformación.

Este detalle explica parte de la sustitución de RFC 3230. Su lenguaje sobre «instancias» generó interpretaciones incompatibles entre contenido y representación. Los nuevos nombres reducen la ambigüedad, pero sólo si registros y pruebas conservan la distinción.

El diccionario no es una credencial

Los dos campos usan diccionarios de Structured Fields: las claves indican algoritmos y los valores llevan secuencias de bytes. Es posible anunciar más de un algoritmo para facilitar una transición.

Parsear la estructura no significa aceptarla. La organización necesita una lista explícita de algoritmos permitidos y una regla para valores múltiples. El registro de IANA informa del estado; RFC 9530 recomienda algoritmos activos y prohíbe los obsoletos en entornos potencialmente adversos.

Base64 sólo representa bytes. El resumen calcula una función sobre bytes. La firma vincula componentes seleccionados con una clave. Un sistema que denomina «firma» a un resumen borra tres pruebas diferentes.

Tampoco los campos Want-* crean una obligación. Expresan interés y preferencias relativas, pero pueden ignorarse. Si una ruta requiere integridad, esa exigencia pertenece a la política de la aplicación y debe fallar de forma observable.

Firmar el campo no elimina la segunda comprobación

RFC 9421 permite que una firma de mensaje HTTP cubra Content-Digest, además del método, el destino u otros componentes. Eso protege el valor declarado contra cambios y puede asociarlo a una clave.

Sin embargo, la firma cubre componentes seleccionados, no el mensaje entero de forma implícita. Si el campo no figura en la base de firma, una firma válida no dice nada sobre él. Si sí figura, el receptor todavía debe recalcular el resumen del cuerpo recibido.

El caso crítico es simple: se conserva el Content-Digest firmado y se sustituye el cuerpo por un defecto de intermediación. La firma puede seguir siendo válida porque el campo no cambió. El recálculo independiente descubre que los bytes ya no corresponden.

En sentido contrario, recalcular sin verificar la firma permite que cualquiera entregue cuerpo y resumen coincidentes. Y una firma auténtica aún necesita autorización: la clave correcta puede carecer de permiso para esa operación. Cobertura, algoritmo, vigencia y controles contra repetición forman parte del perfil de la aplicación.

La cola llega después del cuerpo

RFC 9530 permite enviar el campo como cabecera o como tráiler. El tráiler resuelve un problema de emisión continua: el remitente no conoce el resumen hasta terminar. Para el receptor crea una obligación temporal: no debe confirmar el efecto antes de recibirlo y validarlo.

Una importación que escribe cambios mientras consume el flujo y mira el tráiler al final puede descubrir el error después del compromiso. Debe preparar el contenido en una zona reversible o mantener la transacción abierta hasta completar las comprobaciones.

HTTP/1.1, HTTP/2 y HTTP/3 transportan los tráileres con mecanismos distintos. Los intermediarios y marcos no siempre los conservan ni los presentan igual. Una prueba real debe atravesar cada ruta y demostrar que el decisor recibe el campo antes de actuar.

Integridad no significa actualidad

Una respuesta en caché conserva su resumen mientras sus bytes no cambien. Puede estar caducada. RFC 9111 determina frescura, revalidación y uso de contenido obsoleto por reglas independientes.

Una petición firmada también puede repetirse intacta. Su cuerpo, resumen y firma pasan otra vez. Sólo una ventana temporal, un nonce, un identificador o una política de idempotencia decide si la segunda ejecución es válida.

Lo mismo ocurre con el significado. Un documento puede ser válido según el esquema y aun conceder privilegios peligrosos. Un paquete puede coincidir con el resumen del editor y contener código vulnerable. La integridad preserva el objeto; no aprueba sus consecuencias.

Probar el límite, no el caso feliz

La primera prueba debe entregar contenido hostil y su resumen correcto. El control de integridad debe aprobarlo y la autorización denegarlo. Después se cambia un byte conservando el resumen y se exige un fallo anterior a cualquier modificación de estado.

Hay que firmar una solicitud sin cubrir Content-Digest, y luego cubrir el campo pero alterar el cuerpo. Se prueban algoritmos múltiples y degradados, compresión, rangos y reconstrucción de representaciones. El orden de los miembros nunca debe imponer un algoritmo débil.

Finalmente se envía el campo como tráiler a través de cada versión HTTP, se repite una solicitud válida y se sirve una respuesta en caché ya obsoleta. Cada puerta debe producir su propio resultado. Una sola luz verde no puede representar todo el recorrido.