Planteamiento y alcance
Un socio de pagos requiere prueba del remitente y de la integridad de cada solicitud HTTP. Utilizando RFC 9421, diseña la firma y verificación, y explica los componentes cubiertos, la defensa contra reenvíos (replay), la rotación de claves y las reescrituras de proxies.
RFC 9421 separa la entrada de la firma, los componentes HTTP cubiertos y parámetros tales como created, expires y nonce. La pregunta evalúa si el candidato puede hacer interoperables el "quién firmó" y "qué bytes se firmaron", en lugar de limitarse a calcular el hash de un cuerpo.
Qué evalúa el entrevistador
Evaluar si los componentes cubiertos vinculan la semántica de la solicitud; si ambas partes canonicalizan la base de firma de manera idéntica; si el tiempo, el nonce y el ID de clave detienen los ataques de repetición; cómo los proxies, reintentos, compresión e inquilinos (tenants) afectan la verificación; y si la publicación, revocación y monitoreo de claves son operables.
Estructura de respuesta en 30 segundos
"Exigiría que el método, la ruta de destino, la autoridad, los campos comerciales importantes y Content-Digest estén cubiertos, con un algoritmo fijo, orden de parámetros y tolerancia de reloj. El servidor analiza Signature-Input, reconstruye la misma base, localiza la clave, verifica la firma, comprueba created, expires y un nonce de un solo uso, y solo entonces pasa a la lógica de negocio. Los ID de clave con control de versiones admiten doble verificación y revocación. Un proxy solo puede reescribir campos no cubiertos; de lo contrario, la verificación falla."
Respuesta detallada paso a paso
Paso 1: Definir la propiedad a demostrar
Una firma demuestra que el titular de una clave firmó determinados componentes HTTP seleccionados y ayuda a detectar manipulaciones. No reemplaza a TLS, a la autorización, a la validación de entradas ni a la idempotencia de negocio. Especifica si el protocolo requiere autenticación, integridad o no repudio.
Paso 2: Seleccionar los componentes cubiertos
Cubre como mínimo el método, la ruta de destino y la autoridad. Añade content-digest, una clave de idempotencia, el ID de inquilino o campos críticos del negocio según sea necesario. No firmes un solo campo reemplazable ni cubras a ciegas encabezados que un proxy legítimo deba reescribir. Versiona la lista de componentes como parte del protocolo.
Paso 3: Canonicalizar la base de firma
Ambas partes deben seguir las reglas de RFC 9421 para identificadores de componentes, ordenamiento, codificación de parámetros y componentes derivados. El servidor debe reconstruir la base a partir de la solicitud analizada y de Signature-Input, sin adivinar mediante la concatenación directa de cadenas de encabezados sin procesar. Rechaza componentes críticos desconocidos o duplicados.
Paso 4: Proteger el contenido de la solicitud
Para solicitudes con cuerpo, calcula Content-Digest e inclúyelo en la firma. Antes de la verificación, aplica una función de hash a los bytes recibidos para que la compresión, transcodificación o reformateo de JSON no puedan alterar el contenido silenciosamente. Si un proxy descomprime o vuelve a codificar, define si la firma se genera antes o después de esa transformación.
Paso 5: Añadir tiempo y defensa contra reenvíos (replay)
Exige created y, cuando sea útil, exige expires y un nonce único. Verifica la ventana de tiempo y el desvío de reloj (clock skew), y almacena brevemente los nonces utilizados por inquilino. Los reintentos de la misma solicitud de negocio dependen de una clave de idempotencia en lugar de una vigencia ilimitada de la firma. Superar la comprobación de tiempo no hace que una escritura sea segura de ejecutar dos veces.
Paso 6: Descubrir y rotar claves
El ID de clave en Signature-Input selecciona una clave pública desde un directorio controlado o un endpoint tipo JWKS. Almacena en caché los resultados versionados. Durante la rotación, publica la nueva clave, permite claves antiguas y nuevas durante un período de superposición limitado y luego revoca la clave antigua una vez que el tráfico se haya drenado. Mantén las claves privadas en los endpoints de firma y nunca registres en logs material de claves ni una base de firma completa.
Paso 7: Definir límites de proxies y reintentos
Documenta qué capas pueden agregar campos de rastreo, reintentar solicitudes o cambiar la autoridad. Una reescritura no autorizada de un componente cubierto debe provocar el fallo de la verificación. Un proxy no puede copiar un nonce de un solo uso ni reenviar una firma a otro destino. No ejecutes escrituras ni lógica de negocio costosa antes de la verificación.
Paso 8: Gestionar fallos de forma segura
Registra el ID de clave, la versión de firma, la clase de fallo, el desvío de reloj, colisiones de nonces, componentes faltantes y la fuente del proxy junto con un ID de solicitud. Proporciona a los socios clases accionables como expirado, clave desconocida o discordancia de resumen (digest mismatch), sin devolver material de claves ni bases detalladas que ayuden a atacantes a sondear el sistema.
Compensaciones y límites
Firmas asimétricas frente a claves compartidas
Las claves asimétricas simplifican la verificación entre múltiples partes y la revocación independiente, pero requieren más infraestructura. Un HMAC compartido es menos costoso, pero cualquier verificador puede falsificar solicitudes; utilízalo únicamente cuando el límite de confianza esté explícitamente definido.
Cobertura frente a compatibilidad con proxies
Una mayor cobertura proporciona mayor integridad, pero puede fallar cuando una pasarela (gateway) modifica legítimamente un campo. Incluye el contrato del proxy en el protocolo y vuelve a firmar en el límite cuando sea necesario, en lugar de debilitar silenciosamente la verificación.
Ventanas de tiempo reducidas frente a reintentos fuera de línea
Las ventanas cortas reducen el riesgo de ataques de repetición, pero exigen sincronización de reloj y reintentos rápidos. Los clientes fuera de línea deben solicitar una nueva firma en lugar de reutilizar una de larga duración; el servidor puede aplicar una tolerancia acotada y específica por socio.
Pruebas de fallos y evolución
Un proxy cambia la ruta
Reescribe la ruta o la autoridad en un proxy de prueba y confirma que la verificación falle antes de llegar a la lógica de negocio. Los cambios permitidos en los encabezados de rastreo no deben afectar la firma.
Se repite una solicitud antigua
Envía la misma firma y nonce dos veces y verifica que el segundo intento sea rechazado. Utiliza un nuevo nonce con la misma clave de idempotencia y verifica la idempotencia a nivel de la capa de negocio.
Rotación de una clave
Publica simultáneamente las claves antiguas y nuevas y verifica las firmas que cumplan con la política. Tras la revocación, las firmas antiguas deben fallar y las cachés desactualizadas no deben mantenerlas válidas de forma indefinida.
Errores comunes y preguntas de seguimiento
Error 1: Firmar únicamente el hash del cuerpo
Pregunta si la firma se puede copiar a otra ruta o método; los componentes cubiertos del destino deben vincular el significado de la solicitud.
Error 2: Asumir que HTTPS es suficiente
Pregunta cómo se autentican el remitente original y el contenido tras pasar por un proxy interno que termina la conexión TLS.
Error 3: Ignorar el nonce y el tiempo
Pregunta si una solicitud de pago interceptada se puede reenviar durante su ventana de validez; combina tiempo, nonce e idempotencia.
Error 4: Eliminar la clave antigua de inmediato
Pregunta cómo se solapan las solicitudes en tránsito y las cachés multirregión; realiza doble verificación antes de revocar.
Error 5: Devolver detalles de la base de firma en caso de fallo
Pregunta cómo depuran los socios sin exponer material de claves, entradas firmadas o detalles internos del proxy.
Preguntas de seguimiento extendidas y respuestas de referencia
¿Por qué incluir Content-Digest en la firma?
El digest representa los bytes del cuerpo; la firma vincula ese digest al método, al destino y a otros componentes, de modo que un digest válido no pueda trasladarse a otra solicitud.
¿Debe un proxy volver a firmar tras una reescritura?
Si la reescritura forma parte del protocolo aguas abajo, el proxy límite debe firmar con su propia identidad. De lo contrario, debe preservar los componentes cubiertos para que la firma original siga siendo verificable.
¿En qué se diferencian la autenticación y la autorización?
La verificación demuestra que el titular de una clave firmó la solicitud. La autorización continúa comprobando inquilino, cuenta, monto, idempotencia y estado de negocio; una firma por sí sola no puede autorizar la ejecución.