Enunciado y alcance
Una API de carga de archivos debe permitir a los clientes verificar que el contenido HTTP no haya sido reescrito por una puerta de enlace (gateway) o caché. Con base en RFC 9530, diseña el uso de Content-Digest, Repr-Digest y Want-Repr-Digest, y explica sus límites con TLS, firmas y reintentos.
La pregunta evalúa si puedes vincular un resumen (digest) a la capa HTTP correcta: Content-Digest cubre el contenido real del mensaje, Repr-Digest describe la representación seleccionada y Want-Repr-Digest expresa la preferencia del receptor por los resúmenes de representación. Un resumen comprueba la integridad del contenido; por sí solo no prueba quién envió el mensaje.
Qué está evaluando el entrevistador
Aborda la distinción entre el contenido del mensaje y las representaciones, la selección segura de algoritmos, la negociación de solicitudes y respuestas, los límites de proxy y compresión, el cómputo en streaming, la máquina de estados ante fallos de resumen y la combinación correcta de resúmenes con autenticación, TLS, reintentos e idempotencia.
Una respuesta en 30 segundos
“Primero defino el objeto y el límite de bytes que se están verificando. El cliente de carga calcula Content-Digest y el servidor lo verifica mientras procesa en streaming el mensaje recibido. El servidor puede devolver Repr-Digest, el cual el cliente comprueba contra la representación final. Want-Repr-Digest comunica las preferencias de algoritmos; el servidor elige únicamente un algoritmo robusto permitido y registra el resultado. Una discrepancia detiene la entrega o persistencia. La autenticación del remitente continúa proviniendo de TLS, HTTP Message Signatures o un token de acceso.”
Solución paso a paso
Paso 1: Definir el objeto protegido
Indica si el objetivo es el contenido del mensaje transferido o una representación después de la negociación de contenido. Content-Digest aplica al contenido real del mensaje; Repr-Digest describe la representación seleccionada. Un resumen de representación no puede validar una secuencia de bytes diferente tras una transcodificación.
Paso 2: Seleccionar algoritmos de resumen
Utiliza una lista de permitidos con algoritmos aprobados actualmente, tales como SHA-256 o SHA-512, y rechaza opciones heredadas como MD5 o SHA-1. Al analizar el campo estructurado, rechaza algoritmos duplicados, parámetros desconocidos y codificaciones con formato incorrecto para que diferentes librerías no puedan interpretar un mismo valor de forma distinta.
Paso 3: Verificar solicitudes
El cliente de carga calcula Content-Digest sobre los bytes finales del mensaje. El servidor lo calcula durante la lectura y solo realiza la comparación una vez que el mensaje termina. Una discrepancia impide la confirmación (commit) del objeto y la publicación de eventos; la salida parcial nunca se trata como un éxito. Las cargas grandes deben procesarse en streaming en lugar de almacenarse en memoria (buffering).
Paso 4: Verificar respuestas
El servidor puede enviar Repr-Digest en la respuesta. El cliente calcula el resumen sobre la representación seleccionada y decodificada de acuerdo con la regla negociada. Si hay compresión involucrada, el protocolo debe establecer si el resumen cubre el mensaje comprimido o la representación sin comprimir; los clientes no deben mezclar esas capas.
Paso 5: Usar Want-Repr-Digest
Un cliente puede enviar Want-Repr-Digest con preferencias de algoritmos y pesos. El servidor puede satisfacerlo, seleccionar otro algoritmo permitido u omitir el campo de respuesta. El cliente debe distinguir entre “resumen no proporcionado” y “discrepancia de resumen”; la ausencia no es una verificación exitosa.
Paso 6: Manejar proxies y cachés
Un acierto de caché (cache hit) aún necesita un resumen que coincida con la representación actual. Si una puerta de enlace recompime, transcodifica o combina contenido, debe recalcular el resumen correspondiente; copiar el campo aguas arriba (upstream) crea un resultado falso. Reescribir un campo fuera de los bytes cubiertos por el resumen no invalida automáticamente el resumen, pero puede alterar la semántica de la firma o de la autorización.
Paso 7: Combinar autenticación y protección contra retransmisiones (replay protection)
Un resumen demuestra una relación de bytes, no la identidad del remitente, y no impide que un mensaje válido se envíe nuevamente. Utiliza TLS, HTTP Message Signatures o tokens para la autenticación del remitente. Utiliza un nonce, una ventana de tiempo y una clave de idempotencia de negocio para evitar cobros duplicados. Un valor de resumen no es una credencial de autorización.
Paso 8: Definir fallos y observabilidad
Expón métricas y clases de error separadas para discrepancias, algoritmos no permitidos, campos con formato incorrecto y campos faltantes. Limpia los objetos temporales después de que falle la verificación de la carga; descarta una respuesta en caché no verificada y activa la política de reintentos. Registra el algoritmo, el ID de solicitud, el tamaño y la clase de fallo; nunca contenido sensible ni una carga útil completa.
Compensaciones (trade-offs) y límites
Content-Digest o Repr-Digest
Content-Digest es adecuado para verificar lo que realmente transfirió este mensaje HTTP. Repr-Digest es adecuado para cachés, negociación de contenido y verificación de representaciones de recursos. Pueden coexistir, pero el protocolo debe documentar los límites de bytes y el orden de decodificación.
Resumen o firma digital
Los resúmenes son económicos y detectan cambios en tránsito o almacenamiento. Las firmas digitales autentican adicionalmente al titular de una clave y admiten la verificación entre sistemas. Una firma puede cubrir un campo de resumen para vincular la integridad del contenido al método y al destino, pero el resumen por sí mismo no tiene propiedades de identidad.
Fallar de forma cerrada (fail closed) o degradar
Los pagos, paquetes de software y archivos regulados deben rechazar resúmenes faltantes o no coincidentes. Un recurso estático ordinario con un resumen opcional puede continuar tras registrar una alerta, pero la entidad que llama debe saber que la integridad no fue verificada; no debe marcarse silenciosamente como confiable.
Simulacros de fallos y evolución
La puerta de enlace recompime una respuesta
Haz que una puerta de enlace cambie la compresión y luego verifica que el cliente siga calculando el hash de la capa de representación definida por el protocolo. Si la puerta de enlace modificó la capa cubierta, debe generar un nuevo campo.
Un byte cambia durante la carga
Reemplaza un byte en un proxy y verifica que el servidor reporte una discrepancia de Content-Digest antes de confirmar el objeto, y que luego elimine los datos temporales y los eventos posteriores (downstream).
Degradación de algoritmo o campo faltante
Envía una preferencia que contenga un algoritmo heredado y verifica que el servidor rechace la opción no permitida. Elimina Repr-Digest y confirma que el cliente entre en una rama de “no verificado” en lugar de una rama de éxito.
Errores comunes y preguntas de seguimiento
Error 1: Tratar un resumen como autenticación
Pregunta de seguimiento: ¿Puede un atacante recalcular el resumen para su propio contenido? Sí. Aún se requiere TLS, una firma o un token para autenticar al remitente.
Error 2: Ignorar las capas de compresión y representación
Pregunta de seguimiento: ¿Se puede copiar un resumen aguas arriba a una respuesta recompimida? Solo cuando la capa de bytes cubierta no cambia; de lo contrario, debe recalcularse.
Error 3: Tratar un campo faltante como verificado
Pregunta de seguimiento: ¿Qué sucede si el servidor omite un resumen solicitado? Marca el resultado como no verificado o recházalo según la política; la omisión no equivale a una coincidencia.
Preguntas de seguimiento más profundas y respuestas modelo
¿Por qué una solicitud de carga puede usar Content-Digest?
El remitente puede proporcionar un resumen antes de la transmisión o al completarse el flujo (stream), permitiendo que el receptor verifique los bytes antes de la persistencia. Los objetos grandes deben calcularse de forma incremental mediante hash en lugar de almacenarse en búfer.
¿Son los campos de resumen una protección contra retransmisiones (replay protection)?
No. El mismo mensaje válido puede enviarse nuevamente. La protección contra retransmisiones requiere ventanas de tiempo, nonces, cobertura de firmas y estado de idempotencia del negocio.
¿Debe un proxy eliminar un resumen aguas arriba?
Solo cuando haya modificado los bytes cubiertos y no pueda recalcular el campo debe eliminarlo o marcarlo como inutilizable. Si puede recalcularlo, debe generar un valor para el mensaje o representación final y documentar el límite de responsabilidad.