Verificar que el informe de multas descargado llegó completo
Un HTTPS exitoso no prueba que el archivo almacenado sea el esperado. Tamaño, revisión y digest permiten detectar truncamientos o cambios antes de importarlo.
Por Marco Ferreiro ·
La descarga del informe de infracciones de una flota puede terminar incompleta, mezclada con otra revisión o modificada antes de la importación, aunque el servidor haya respondido 200. El archivo quizá abra igual y conserve un nombre plausible. Si el sistema sólo comprueba que existe, el problema aparece recién cuando faltan filas o cambian resultados.
La verificación útil combina cuatro datos: identidad del informe de multas, revisión, tamaño y digest. Ninguno se deduce del nombre del archivo.
Integridad no es lo mismo que autenticación
TLS protege la comunicación con el servidor durante la conexión. La autenticación indica con qué servicio estamos hablando. La autorización define si podemos pedir el reporte. La integridad del artefacto responde otra pregunta: ¿los bytes que vamos a importar son exactamente los esperados?
Un digest criptográfico resume una secuencia de bytes. Si cambia un byte, el resultado debería cambiar de manera detectable. FIPS 180-4 define la familia SHA-2, que incluye SHA-256 y SHA-512.
El digest no cifra el reporte ni prueba por sí solo quién lo produjo. Su valor depende de que el esperado llegue por un canal confiable o quede protegido por una firma.
El manifiesto mínimo del reporte
Antes de descargar, el productor debería emitir o permitir recuperar un manifiesto con:
- identificador estable del reporte;
- revisión o versión;
- instante de cierre;
- formato y compresión;
- tamaño exacto en bytes;
- algoritmo de digest;
- valor del digest;
- estado del artefacto;
- vencimiento, si corresponde.
El consumidor guarda ese manifiesto separado del archivo. No inventa la revisión usando la fecha local ni confía en multas-final.csv, un nombre que puede repetirse.
Si se regenera el informe porque una jurisdicción corrigió un acta, nace una revisión distinta aunque abarque el mismo período. Sobrescribir impide explicar qué bytes se procesaron.
Content-Digest y Repr-Digest no son intercambiables
RFC 9530 define Content-Digest para el contenido concreto de un mensaje HTTP y Repr-Digest para datos de representación seleccionados. La diferencia importa cuando intervienen compresión, rangos o transformaciones.
Si el servidor calcula el digest sobre el archivo comprimido enviado y el cliente lo compara contra el CSV ya descomprimido, nunca coincidirán. Ambos deben acordar qué secuencia de bytes cubre el valor.
El contrato documenta esa elección. No se corrige quitando campos o volviendo a serializar un JSON, porque la reserialización puede cambiar espacios u orden sin alterar el significado.
Verificación antes de importar
El flujo seguro para incorporar un informe de actas es corto:
- recuperar el manifiesto autorizado;
- descargar a un archivo temporal aislado;
- confirmar que la transferencia terminó;
- medir tamaño en bytes;
- calcular el digest con el algoritmo declarado;
- comparar tamaño y digest;
- mover el archivo a almacenamiento inmutable;
- iniciar la importación con esa revisión.
El importador de actas recibe el identificador del artefacto verificado, no una ruta arbitraria. Así se evita que otro proceso reemplace el archivo entre el control y la lectura.
Un experimento reproducible
Creamos un CSV sintético con diez actas y calculamos SHA-256. El manifiesto registra tamaño y digest. Una descarga íntegra coincide en ambos controles.
Después repetimos dos alteraciones:
- quitamos los últimos bytes;
- cambiamos un carácter dentro de una fila.
El truncamiento reduce el tamaño y modifica el digest. El cambio de un carácter conserva el tamaño, pero modifica el digest. Esto muestra por qué ambos controles aportan información: el tamaño detecta rápido ciertas fallas; el digest cubre alteraciones del mismo largo.
No publicamos el digest de un informe real como si eso anonimizara las patentes que contiene. Un hash no convierte información personal en pública.
Qué hacer cuando no coincide
Una discrepancia no se repara agregando un salto de línea ni aceptando “casi todas las actas”. El archivo se mueve a cuarentena y se registra:
- identificador y revisión esperados;
- tamaño y digest recibidos;
- etapa de la falla;
- intento de descarga;
- correlación de la solicitud;
- decisión de reintento.
El consumidor solicita otra descarga de la misma revisión. Si el productor cambió el artefacto, debe emitir una revisión nueva con manifiesto nuevo. Reutilizar el digest anterior escondería una modificación.
Descargas partidas y rangos HTTP
Los rangos permiten reanudar un informe grande, pero agregan riesgo de mezclar actas de revisiones distintas. RFC 9110 describe las respuestas parciales y sus validadores.
Antes de concatenar, cada fragmento necesita posición y pertenencia al mismo artefacto. Al final se verifica el digest del conjunto completo. Que cada parte tenga el tamaño esperado no garantiza que estén en orden ni que correspondan a la misma revisión.
Si el servidor no ofrece un validador estable, es más seguro reiniciar que combinar respuestas obtenidas en momentos diferentes.
Digest, firma y procedencia
Un atacante que pueda cambiar el archivo y el manifiesto puede recalcular el digest. Para autenticidad, el manifiesto puede protegerse con una firma vinculada a la identidad del emisor. RFC 9421 define firmas de componentes de mensajes HTTP; su alcance y gestión de claves deben documentarse.
Otra opción es obtener el manifiesto desde un endpoint autenticado separado y registrar la conexión. En ambos casos, la procedencia incluye quién emitió el valor, cuándo y para qué revisión.
No se usa el digest como contraseña ni token. Puede viajar en logs, pero las actas del informe siguen protegidas.
Importaciones idempotentes
La integridad del archivo no evita importar dos veces las mismas actas. La importación debe registrar reportId y revision, y rechazar o reconocer un reenvío ya aplicado.
El digest ayuda a distinguir dos situaciones:
- misma identidad, misma revisión y mismos bytes: reintento idempotente;
- misma identidad o revisión, pero bytes distintos: conflicto que exige investigación.
No conviene tratar el segundo caso como actualización silenciosa: rompe la trazabilidad de las multas ya informadas.
Monitoreo sin exponer el reporte
Las métricas pueden contar descargas verificadas, discrepancias, reintentos y tiempo hasta la importación. No necesitan nombres de archivo con patentes ni contenido de filas.
Los logs guardan digest, revisión y correlación, pero aplican límites de acceso y retención. Para soporte, un operador puede confirmar que dos sistemas usaron el mismo artefacto sin abrirlo.
Una alerta se dispara antes del procesamiento. Importar actas y avisar después convierte una protección preventiva en una explicación del daño.
Qué garantiza este diseño
Tamaño y digest no aseguran que los datos sean verdaderos ni completos desde el punto de vista del organismo. Garantizan que el consumidor recibió la secuencia de bytes vinculada al manifiesto y que puede detectar cambios posteriores.
Esa afirmación acotada es valiosa: permite reproducir una importación, aislar truncamientos y distinguir una revisión legítima de una alteración. En una integración de infracciones, donde una fila ausente puede interpretarse erróneamente como “sin multas”, verificar el artefacto antes de usarlo es parte del contrato, no un detalle de almacenamiento.
Metodología
- Alcance
- Prueba reproducible con un reporte sintético descargado, verificado y luego alterado o truncado de forma controlada.
- Unidad de análisis
- Un artefacto binario identificado por revisión, tamaño, algoritmo y digest calculado sobre sus bytes exactos.
- Cobertura
- RFC 9530, RFC 9110, RFC 9421 y FIPS 180-4 consultados el 14 de agosto de 2026.
Limitaciones
- Un hash sin una fuente confiable para el valor esperado sólo permite comparar bytes, no atribuir autoría.
- Las transformaciones de representación deben definirse antes de elegir entre Content-Digest y Repr-Digest.
Fuentes
- RFC 9530 — Digest Fields — RFC Editor (consultada el )
- FIPS 180-4 — Secure Hash Standard — National Institute of Standards and Technology (consultada el )
- RFC 9110 — HTTP Semantics — RFC Editor (consultada el )
- RFC 9421 — HTTP Message Signatures — RFC Editor (consultada el )
Preguntas frecuentes
¿HTTPS ya garantiza que el archivo guardado sea correcto?
Protege el canal, pero no evita todos los errores posteriores, como truncamiento en almacenamiento, asociación con otra revisión o modificación accidental después de descargar.
¿Un digest demuestra quién creó el reporte?
No por sí solo. Detecta cambios respecto de un valor esperado. La autenticidad exige confiar en cómo se obtuvo ese valor o protegerlo con una firma y una identidad verificable.
¿Conviene usar MD5 para este control?
Para un diseño nuevo usamos algoritmos vigentes como SHA-256 o SHA-512. El algoritmo forma parte del contrato y debe poder rotarse sin reinterpretar valores anteriores.
Notas relacionadas
Firmas HTTP y replay en una integración de multas
Una firma válida puede reenviarse si no cubre método, destino, contenido y tiempo. Nonce, ventana de vigencia y almacenamiento atómico permiten detectar duplicados.
Un PDF oficial cambió: cómo probar qué versión se consultó
Una URL oficial puede servir un archivo distinto con el tiempo. Fecha, hash, encabezados y metadatos permiten demostrar qué bytes se consultaron sin confundirlos con autenticidad.
Proveniencia campo por campo: de dónde salió el monto de un acta
Citar una fuente global no alcanza cuando monto, estado y fecha provienen de observaciones distintas. Cada valor normalizado necesita origen, regla y momento auditables.