6. Considerazioni sulla sicurezza
6.1. I messaggi HTTP non sono protetti completamente
Questo documento specifica un meccanismo di integrità dei dati che protegge i dati di rappresentazione o il contenuto HTTP, ma non i campi di intestazione e trailer HTTP, da determinati tipi di corruzione.
I campi di integrità non sono intesi come una protezione generale contro la manomissione dannosa dei messaggi HTTP. In assenza di meccanismi di sicurezza aggiuntivi, un attore dannoso sul percorso può rimuovere interamente un valore di digest o sostituirlo con un nuovo valore di digest calcolato su dati di rappresentazione o contenuto manipolati. Questo attacco può essere mitigato combinando i meccanismi descritti in questo documento con altri approcci come Transport Layer Security (TLS) o firme digitali (ad esempio, HTTP Message Signatures [SIGNATURES]).
6.2. Integrità end-to-end
I campi di integrità possono aiutare a rilevare la modifica dei dati di rappresentazione o del contenuto a causa di errori di implementazione, "proxy di trasformazione" indesiderati (vedere la Sezione 7.7 di [HTTP]) o altre azioni mentre i dati passano attraverso più hop o confini di sistema. Anche un semplice meccanismo per l'integrità dei dati di rappresentazione end-to-end è prezioso perché un agente utente può convalidare che il recupero della risorsa è riuscito prima di passare a un parser HTML, lettore video, ecc., per l'analisi.
Si noti che l'utilizzo di questi meccanismi da soli non fornisce l'integrità end-to-end dei messaggi HTTP su più hop poiché i metadati potrebbero essere manipolati in qualsiasi fase. I metodi per proteggere i metadati sono discussi nella Sezione 6.3.
6.3. Utilizzo nelle firme
Le firme digitali sono ampiamente utilizzate insieme ai checksum per fornire l'identificazione certa dell'origine di un messaggio [FIPS186-5]. Tali firme possono proteggere uno o più campi HTTP e ci sono ulteriori considerazioni quando i campi di integrità sono inclusi in questo set.
Non ci sono restrizioni sul tipo o formato di firma digitale con cui possono essere utilizzati i campi di integrità. Un possibile approccio è combinarli con HTTP Message Signatures [SIGNATURES].
I digest dipendono esplicitamente dai "metadati di rappresentazione" (ad esempio, i valori di Content-Type, Content-Encoding, ecc.). Una firma che protegge i campi di integrità ma non altri "metadati di rappresentazione" può esporre la comunicazione a manomissioni. Ad esempio, un attore potrebbe manipolare il valore del campo Content-Type e causare un errore di convalida del digest presso il destinatario, impedendo all'applicazione di accedere alla rappresentazione. Un tale attacco consuma le risorse di entrambi gli endpoint. Vedere anche la Sezione 3.2.
È probabile che le firme siano considerate un'impostazione avversaria quando si applicano i campi di integrità; vedere la Sezione 5. Repr-Digest offre una possibilità interessante se combinato con le firme. Nello scenario in cui non c'è contenuto da inviare, il digest di una stringa vuota può essere incluso nel messaggio e, se firmato, può aiutare il destinatario a rilevare se il contenuto è stato aggiunto a seguito di un incidente o di una manipolazione intenzionale. È supportato anche lo scenario opposto; includere un campo di integrità per il contenuto e firmarlo può aiutare un destinatario a rilevare dove il contenuto è stato rimosso.
Qualsiasi alterazione dei campi di integrità potrebbe influenzare la convalida della firma. Esempi di tale alterazione includono la deduplicazione dei digest o la combinazione di diversi valori di campo (vedere la Sezione 5.2 di [HTTP]).
6.4. Utilizzo nei campi trailer
Prima di inviare campi di integrità in una sezione trailer, il mittente dovrebbe considerare che gli intermediari sono esplicitamente autorizzati a eliminare qualsiasi trailer (vedere la Sezione 6.5.2 di [HTTP]).
Quando i campi di integrità vengono utilizzati in una sezione trailer, i valori dei campi vengono ricevuti dopo il contenuto. L'elaborazione anticipata del contenuto prima della sezione trailer impedisce la convalida del digest, portando potenzialmente all'elaborazione di dati non validi.
Uno dei vantaggi dell'utilizzo dei campi di integrità in una sezione trailer è che consente l'hashing dei byte mentre vengono inviati. Tuttavia, è possibile progettare un algoritmo di hashing che richieda l'elaborazione del contenuto in modo tale da negare questi vantaggi. Ad esempio, Merkle Integrity Content Encoding [MICE] richiede che il contenuto venga elaborato in ordine inverso. Ciò significa che i dati completi devono essere disponibili, il che significa che c'è una differenza di elaborazione trascurabile nell'invio di un campo di integrità in un'intestazione rispetto a una sezione trailer.
6.5. Variazioni all'interno di Content-Encoding
I meccanismi di codifica del contenuto possono supportare diversi parametri di codifica, il che significa che lo stesso contenuto di input può produrre output diversi. Ad esempio, GZIP supporta più livelli di compressione. Tali parametri di codifica non sono generalmente comunicati come metadati di rappresentazione. Ad esempio, diversi livelli di compressione utilizzerebbero tutti lo stesso campo "Content-Encoding: gzip". Altri esempi includono dove la codifica si basa su nonce o timestamp, come la codifica del contenuto aes128gcm definita in [RFC8188].
Poiché è possibile che vi siano variazioni all'interno della codifica del contenuto, il checksum trasmesso dai campi di integrità non può essere utilizzato per fornire una prova di integrità "a riposo" a meno che l'intero contenuto non sia persistente.
6.6. Agilità dell'algoritmo
Le proprietà di sicurezza degli algoritmi di hashing non sono fisse. L'agilità dell'algoritmo (vedere [RFC7696]) si ottiene fornendo alle implementazioni la flessibilità di scegliere algoritmi di hashing dal registro IANA Hash Algorithms for HTTP Digest Fields; vedere la Sezione 7.2.
La transizione da algoritmi deboli è supportata dalla negoziazione dell'algoritmo di hashing utilizzando Want-Content-Digest o Want-Repr-Digest (vedere la Sezione 4) o inviando più digest tra cui il ricevitore sceglie. Un ricevitore che dipende da un digest per la sicurezza sarà vulnerabile agli attacchi sull'algoritmo più debole che è disposto ad accettare. Gli endpoint sono avvisati che l'invio di più valori consuma risorse che potrebbero essere sprecate se il ricevitore li ignora (vedere la Sezione 3).
Mentre l'agilità dell'algoritmo consente la migrazione ad algoritmi più forti, non impedisce l'uso di algoritmi più deboli. I campi di integrità non forniscono alcuna mitigazione per attacchi di downgrade o sostituzione (vedere la Sezione 1 di [RFC6211]) dell'algoritmo di hashing. Per proteggersi da tali attacchi, gli endpoint potrebbero limitare il loro set di algoritmi supportati a quelli più forti e proteggere i valori dei campi utilizzando TLS e/o firme digitali.
6.7. Esaurimento delle risorse
La convalida del campo di integrità consuma risorse computazionali. Al fine di evitare l'esaurimento delle risorse, le implementazioni possono limitare la convalida dei tipi di algoritmo, il numero di convalide o la dimensione del contenuto. In questi casi, saltare completamente la convalida o ignorare il fallimento della convalida di un algoritmo più preferito lascia la possibilità di un attacco di downgrade (vedere la Sezione 6.6).