Passa al contenuto principale

1.4. Applicazione delle firme dei messaggi HTTP (Application of HTTP Message Signatures)

1.4. Applicazione delle firme dei messaggi HTTP (Application of HTTP Message Signatures)​

Le firme dei messaggi HTTP sono progettate come strumento di uso generale applicabile in molteplici circostanze e applicazioni. Per applicare correttamente e in sicurezza le firme dei messaggi HTTP, un'applicazione o un profilo di questa specifica DEVE specificare, come minimo, tutti gli elementi seguenti:

  • L'insieme di identificatori di componente (Sezione 2) e parametri di firma (Sezione 2.3) che si attende e che è RICHIESTO siano inclusi nell'elenco dei componenti coperti. Ad esempio, un protocollo di autorizzazione potrebbe imporre che il campo Authorization sia coperto per proteggere le credenziali di autorizzazione e che i parametri di firma contengano un parametro created (Sezione 2.3), mentre un'API che si attende contenuto HTTP semanticamente rilevante potrebbe richiedere che il campo Content-Digest definito in [DIGEST] sia presente e coperto e che sia imposto un valore per il parametro tag (Sezione 2.3) specifico dell'API protetta.

  • I tipi Structured Field [STRUCTURED-FIELDS] attesi di eventuali campi o parametri coperti richiesti o attesi.

  • Un mezzo per recuperare il materiale di chiave usato per verificare la firma. Un'applicazione userà di solito il parametro keyid dei parametri di firma (Sezione 2.3) e definirà regole per risolvere una chiave a partire da esso, sebbene la chiave appropriata possa essere nota per altre vie, come la preregistrazione della chiave del firmatario.

  • L'insieme di algoritmi di firma consentiti da usare per i firmatari e da accettare per i verificatori.

  • Un mezzo per stabilire che l'algoritmo di firma usato per verificare la firma è appropriato per il materiale di chiave e il contesto del messaggio. Ad esempio, il processo potrebbe usare il parametro alg dei parametri di firma (Sezione 2.3) per dichiarare esplicitamente l'algoritmo, derivare l'algoritmo dal materiale di chiave o usare un algoritmo preconfigurato concordato tra firmatario e verificatore.

  • Un mezzo per stabilire che una data chiave e un dato algoritmo usati per una firma sono appropriati per il contesto del messaggio. Ad esempio, un server che si attende solo firme ECDSA dovrebbe sapere di rifiutare firme RSA, o un server che si attende crittografia asimmetrica dovrebbe sapere di rifiutare crittografia simmetrica.

  • Un mezzo per determinare il contesto per la derivazione dei componenti del messaggio da un messaggio HTTP e dal suo contesto applicativo. Di norma questo è il messaggio HTTP di destinazione stesso, ma il contesto può includere informazioni aggiuntive note all'applicazione tramite configurazione, come un hostname esterno.

  • Se è necessario un legame tra richiesta e risposta usando il meccanismo fornito nella Sezione 2.4, tutti gli elementi del messaggio di richiesta e del messaggio di risposta che sarebbero necessari per fornire proprietà di tale legame.

  • I messaggi di errore e i codici restituiti dal verificatore al firmatario quando la firma non è valida, il materiale di chiave non è appropriato, la finestra di validità temporale è fuori specifica, un valore di componente non può essere calcolato o si verificano altri errori durante la verifica della firma. Ad esempio, se una firma è usata come meccanismo di autenticazione, un codice di stato HTTP 401 (Unauthorized) o 403 (Forbidden) può essere appropriato. Se la risposta proviene da un'API HTTP, una risposta con un codice di stato HTTP come 400 (Bad Request) può includere maggiori dettagli [RFC7807] [RFC9457], come un indicatore che è stato usato materiale di chiave errato.

Scegliendo questi parametri, un'applicazione delle firme dei messaggi HTTP deve garantire che il verificatore abbia accesso a tutte le informazioni richieste per ricreare la base della firma. Ad esempio, un server dietro un reverse proxy dovrebbe conoscere l'URI di richiesta originale per usare il componente derivato @target-uri, sebbene l'URI di destinazione apparente sia modificato dal reverse proxy (si veda anche la Sezione 7.4.3). Inoltre, un'applicazione che usa firme nelle risposte dovrebbe garantire che i client che ricevono risposte firmate abbiano accesso a tutte le porzioni firmate del messaggio, incluse eventuali porzioni della richiesta firmate dal server con il parametro req ("request-response") (Sezione 2.4).

I dettagli su questo tipo di profilazione rientrano nell'ambito dell'applicazione e sono fuori dall'ambito di questa specifica; tuttavia, ulteriori considerazioni sono discusse nella Sezione 7. In particolare, scegliendo l'insieme richiesto di identificatori di componente, occorre fare attenzione a garantire che la copertura sia sufficiente per l'applicazione, come discusso nelle Sezioni 7.2.1 e 7.2.8. Questa specifica definisce solo parte di un sistema di sicurezza completo per un'applicazione. Costruendo un sistema di sicurezza completo basato su questo strumento, è importante eseguire un'analisi di sicurezza dell'intero sistema, di cui le firme dei messaggi HTTP sono una parte. Sistemi storici, come AWS Signature Version 4 [AWS-SIGv4], possono fornire ispirazione ed esempi su come applicare meccanismi simili a un'applicazione, sebbene l'esame di tali sistemi storici non elimini la necessità di un'analisi di sicurezza di un'applicazione delle firme dei messaggi HTTP.