1. Introduction (Introduzione)
1. Introduction (Introduzione)
Un modello di deployment abbastanza comune per le applicazioni HTTPS consiste nell'avere i server di applicazione HTTP di origine posizionati dietro un proxy inverso che termina le connessioni TLS dai client. Il proxy è accessibile da Internet e distribuisce le richieste dei client al server di origine appropriato all'interno di una rete privata o protetta. I server di origine non sono direttamente accessibili dai client e sono raggiungibili solo attraverso il proxy inverso. I dettagli backend di questo tipo di deployment sono tipicamente opachi ai client che effettuano richieste al server proxy e vedono risposte come se provenissero dal server proxy stesso. Sebbene HTTPS sia generalmente utilizzato anche tra il proxy e il server di origine, la connessione TLS che il client stabilisce per HTTPS è solo tra se stesso e il server proxy inverso.
Il modello di deployment si trova in un numero di varietà come architetture a n livelli (n-tier architectures), reti di distribuzione dei contenuti (content delivery networks), servizi di bilanciamento del carico delle applicazioni (application load-balancing services) e controller di ingresso (ingress controllers).
Sebbene non eccessivamente diffusa, l'autenticazione tramite certificato client TLS (TLS client certificate authentication) viene talvolta impiegata, e in tali casi il server di origine richiede spesso informazioni sul certificato client per la sua logica applicativa. Tale logica può includere decisioni di controllo degli accessi, registrazione di audit e binding di token (tokens) o cookie emessi a un certificato, inclusa la rispettiva validazione di tali binding. I dettagli specifici necessari dal certificato variano anche in base ai requisiti dell'applicazione. Affinché questi tipi di deployment di applicazioni funzionino in pratica, il proxy inverso deve trasmettere informazioni sul certificato client al server di applicazione di origine. Al momento della stesura, un modo comune per trasmettere queste informazioni è utilizzare campi non standard (non-standard fields) per trasportare il certificato (in qualche codifica) o parti individuali di esso nella richiesta HTTP che viene distribuita al server di origine. Questa soluzione funziona, ma l'interoperabilità tra componenti sviluppati indipendentemente può essere complicata o persino impossibile a seconda delle scelte di implementazione rispettivamente effettuate (come quali nomi di campo vengono utilizzati o sono configurabili, quali parti del certificato sono esposte o come il certificato è codificato). Un approccio prevedibile ben noto a questa funzionalità comunemente presente potrebbe migliorare e semplificare l'interoperabilità tra implementazioni indipendenti.
L'ambito di questo documento è descrivere la pratica esistente codificando al contempo dettagli specifici sufficienti per facilitare un'interoperabilità migliorata e a minor contatto. Pertanto, questo documento descrive due campi di intestazione HTTP, "Client-Cert" e "Client-Cert-Chain", che un proxy inverso che termina TLS (TLS Terminating Reverse Proxy, TTRP) aggiunge alle richieste inviate ai server di origine backend. Il valore del campo Client-Cert contiene il certificato client di entità terminale (end-entity client certificate) dalla connessione TLS mutuamente autenticata tra il client di origine e il TTRP. Facoltativamente, il valore del campo Client-Cert-Chain contiene la catena di certificati (certificate chain) utilizzata per la validazione del certificato di entità terminale. Ciò consente al server di origine backend di utilizzare le informazioni del certificato client nella sua logica applicativa. Sebbene possano esserci proxy o hop (hops) aggiuntivi tra il TTRP e il server di origine (potenzialmente anche con connessioni TLS mutuamente autenticate tra loro), l'ambito del campo di intestazione Client-Cert è intenzionalmente limitato all'esposizione al server di origine del certificato che è stato presentato dal client di origine nella sua connessione al TTRP.