4. Security Considerations (Considerazioni sulla sicurezza)
4. Security Considerations (Considerazioni sulla sicurezza)
I campi di intestazione descritti qui consentono a un TTRP e a un server backend o di origine di funzionare insieme come se, dal punto di vista del client, fossero un singolo deployment logico lato server di HTTPS su una connessione TLS mutuamente autenticata. Tuttavia, l'uso dei campi di intestazione al di fuori di quel caso d'uso previsto può compromettere le protezioni offerte dall'autenticazione tramite certificato client TLS. Pertanto, è necessario adottare misure come quelle descritte di seguito per prevenire un uso non intenzionale, sia nell'invio del campo di intestazione che nel fare affidamento sul suo valore.
La produzione e il consumo dei campi di intestazione Client-Cert e Client-Cert-Chain DOVREBBERO essere opzioni configurabili, rispettivamente, in un TTRP e in un server backend (o in un'applicazione individuale su quel server). La configurazione predefinita per entrambi dovrebbe essere di non utilizzare i campi di intestazione, richiedendo quindi un "opt-in" alla funzionalità.
Al fine di prevenire l'iniezione di campo (field injection), i server backend DEVONO accettare solo i campi di intestazione Client-Cert e Client-Cert-Chain da un TTRP fidato (o da un altro proxy in un percorso fidato dal TTRP). Un TTRP DEVE sanificare la richiesta in entrata prima di inoltrarla rimuovendo o sovrascrivendo eventuali istanze esistenti dei campi. Altrimenti, client arbitrari possono controllare i valori dei campi come visti e utilizzati dal server backend. È importante notare che trascurare di prevenire l'iniezione di campo non "fallisce in modo sicuro" (fail safe) nel senso che la funzionalità nominale funzionerà comunque come previsto anche quando sono possibili azioni malevole. Pertanto, si raccomanda particolare attenzione nel garantire che sia in atto una corretta sanificazione dei campi.
La comunicazione tra un TTRP e un server backend deve essere protetta contro intercettazioni e modifiche da parte di soggetti non previsti.
Le opzioni di configurazione e la sanificazione delle richieste sono funzionalità necessarie dei rispettivi server. Gli altri requisiti possono essere soddisfatti in diversi modi, che varieranno in base ai deployment specifici. La comunicazione tra un TTRP e un server backend o di origine, ad esempio, potrebbe essere autenticata in qualche modo con l'inserimento e il consumo dei campi di intestazione Client-Cert e Client-Cert-Chain che si verificano solo su quella connessione. L'Appendice B.3 di [HTTPSIG] fornisce un esempio di ciò con un'applicazione di firme di messaggi HTTP (HTTP Message Signatures). In alternativa, la topologia di rete potrebbe dettare una rete privata tale che l'applicazione backend possa accettare solo richieste dal TTRP e il proxy possa effettuare richieste solo a quel server. Sono possibili anche altri deployment che soddisfano i requisiti qui stabiliti.